Вышла новая версия VMware Cloud Foundation 9.1, об этом вы уже знаете. В этой статье рассматриваются многие новые возможности и улучшения платформы vSphere в составе пакета VCF 9.1. Также рекомендуем ознакомиться с примечаниями к выпуску и уведомлениями о поддержке продуктов для получения важной информации.

Быстрое развёртывание патчей безопасности vCenter

Функция быстрого патчинга vCenter (vCenter Quick Patch) обеспечивает оперативное применение обновлений с минимальным, а в ряде случаев — нулевым временем простоя. Уровень простоя зависит от того, какие именно сервисы подвергаются обновлению. Механизм Quick Patch ориентирован на быстрое устранение критических уязвимостей безопасности в vCenter.

Традиционный in-place патчинг обновляет все RPM-пакеты на vCenter вне зависимости от того, изменился ли соответствующий сервис или компонент. Quick Patch затрагивает только те RPM или бинарные файлы, которые действительно изменились в составе патча. Такой подход кардинально сокращает общее окно обслуживания и снижает время простоя vCenter до менее чем 1 минуты, а в ряде случаев сводит его к нулю.

Благодаря vCenter Quick Patch критически важные обновления безопасности можно применять без прерывания рабочих процессов: развёртывание виртуальных машин и кластеров Kubernetes продолжается в штатном режиме, автоматизированные сценарии и API-вызовы не прерываются. Меньше времени уходит на планирование окон обслуживания — больше на поддержание актуальности патчей.

Подробности — в статье о vCenter Quick Patch.

Упрощение обслуживания vCenter

Помимо Quick Patch, в версии 9.1 улучшены и другие аспекты обслуживания vCenter.

Обновление vCenter с сокращённым временем простоя (Reduced Downtime Upgrade, RDU) теперь поддерживает работу с онлайн-репозиторием. Это упрощает использование метода RDU для подключённых к интернету экземпляров vCenter. Автономный метод с использованием примонтированного ISO по-прежнему доступен. Последующие патчи, обновления и апгрейды vCenter 9.1.x и более поздних версий также можно применять через RDU с онлайн-репозиторием, что значительно упрощает эксплуатацию для подключённых инсталляций.

В vCenter появился новый API, с помощью которого сторонние компоненты могут получать уведомления о планируемом или текущем техническом обслуживании. Обратный прокси Envoy будет отдавать заголовок 503 с информацией о том, что vCenter находится на обслуживании, и указанием ожидаемого времени завершения.

При выполнении мажорных апгрейдов (с 8.x до 9.1.0) или минорных обновлений (с 9.0.x до 9.1.0) методом RDU версия аппаратного обеспечения виртуальной машины vCenter автоматически повышается с версии 10 до версии 17, поскольку создаётся новая ВМ vCenter. При выполнении in-place обновления (с 9.0.x до 9.1.0) версию аппаратного обеспечения ВМ vCenter потребуется обновить вручную — эта процедура требует выключения ВМ vCenter.

Изменение ресурсов vCenter через единый API

В VCF 9.1 появился новый API, упрощающий масштабирование ресурсов vCenter. Для увеличения объёма вычислительных ресурсов и дискового пространства vCenter достаточно одного вызова API и перезагрузки.

Вызов API можно инициировать из Developer Center API Explorer в интерфейсе vCenter. API называется deployment/size и использует метод PATCH.

Упрощение обслуживания хостов ESX

Образы, создаваемые и управляемые через vSphere Lifecycle Manager, теперь включают контрольную сумму SHA256. Она позволяет проверять целостность образов при экспорте и импорте в другие экземпляры vCenter: администратор может сравнить контрольные суммы на источнике и целевом сервере. Речь идёт о контрольной сумме именно определения образа, а не VIB-файлов ESX.

В предыдущих версиях vSphere Lifecycle Manager проверял актуальность прошивок и драйверов устройств по HCL только при наличии стороннего Hardware Support Manager (HSM). Начиная с версии 9.1 вывод информации о текущих драйверах и прошивках устройств, а также их валидация по HCL выполняются для кластеров vSAN даже в отсутствие HSM. Некоторые устройства могут не сообщать данные о прошивке без соответствующего HSM. Это обеспечивает базовый уровень проверки устройств в кластере vSAN.

Подготовка кластеров vSphere с образом и конфигурацией

Zero Touch Provisioning (ZTP) строится на базе существующей инфраструктуры vSphere Auto-Deploy. Механизм задействует современные протоколы загрузки — UEFI HTTP/S Boot — и поддерживает актуальные серверные конфигурации, включая Secure Boot и TPM. ZTP не требует внешнего TFTP-сервера: достаточно настроить URL загрузки UEFI, указывающий на vCenter, и загрузить хост по сети. Если UEFI не поддерживает настройку статического IP для загрузки, потребуется DHCP-сервер.

Образ ESX и конфигурация определяются расположением кластера, выбранным при настройке правила развёртывания. Если для целевого кластера не настроен профиль конфигурации vSphere (VCP), хост загрузится и присоединится к кластеру с конфигурацией по умолчанию.

Быстрое и менее затратное обновление кластеров vSphere

ESX Live Patch включён по умолчанию для всех кластеров и автоматически применяется, если устанавливаемый патч поддерживает этот режим. Если патч несовместим с Live Patch, по умолчанию используется стандартный метод с переходом в режим обслуживания и перезагрузкой хоста.

Параметр можно изменить, включив принудительное применение Live Patch. В этом режиме исправление будет выполняться только через Live Patch, а для хостов, требующих режима обслуживания, процесс патчинга будет заблокирован. Настройки можно задать как на уровне кластера, так и на уровне vCenter — параметры vCenter применяются ко всем кластерам, если они не переопределены на уровне кластера.

ESX Live Patch теперь поддерживает серверы с включённым TPM. Пользователям не нужно отключать TPM или отказываться от Live Patch при использовании ESX 9.1 и более поздних версий.

Поддержка Live Patch расширена: охватывает больше компонентов vmkernel и обеспечивает более высокую производительность при патчинге ядра. Теперь механизм поддерживает дополнительные пользовательские демоны и сервисы, включая демоны vSAN, базовые демоны хранилища и соответствующие библиотеки.

Расширение интеграции с механизмом Desired State Configuration

Профили конфигурации vSphere (vSphere Configuration Profiles) обеспечивают соответствие изменений конфигурации и операций по устранению отклонений требованиям vSAN. Политики режима обслуживания vSAN и политики доступности объектов соблюдаются при исправлении кластеров vSAN. Расширенная конфигурация vSAN может применяться на уровне всего кластера.

Профили конфигурации vSphere используются для настройки memory tiering на хостах кластера. Устройства NVMe могут быть выделены для memory tiering; дополнительное устройство NVMe опционально может быть задействовано в качестве зеркального устройства для программного зеркалирования.

Профили конфигурации vSphere обеспечивают конфигурацию хостов при установке через Zero Touch Provisioning, а также поддерживают начальную настройку vSphere Distributed Switch в процессе развёртывания хоста.

Оптимизация Desired State Configuration

При добавлении новых хостов в кластеры с включёнными профилями конфигурации vSphere желаемая конфигурация автоматически применяется к входящему хосту. Специфичные для хоста атрибуты (например, IP-адреса) извлекаются из него автоматически и добавляются в соответствующий раздел профиля кластера.

Автоматическое устранение отклонений отключено по умолчанию и может быть включено как на уровне vCenter, так и на уровне отдельного кластера. Подробности — в руководстве How to Configure the vSphere Lifecycle Manager Remediation Settings.

Автоматическое управление сертификатами

Сертификат TLS для vCenter теперь обновляется автоматически за 5 дней до истечения срока действия. Сертификат ESX обновляется за 30 дней до истечения. Порог для ESX настраивается через расширенные параметры vCenter Server с помощью параметра vpxd.certmgmt.certs.autoRenewThreshold.

В обоих случаях автоматическое обновление выполняется для сертификатов, управляемых VMCA. Сертификаты, выданные внешними центрами сертификации, не обновляются автоматически — ответственность за их управление лежит на администраторе.

Если до истечения срока действия корневого сертификата VMCA остаётся менее 1 года, в процессе обновления vCenter автоматически обновляются корневой сертификат VMCA, а также дочерние сертификаты решений. Сертификаты TLS для vCenter и ESX в рамках этой операции не обновляются.

Масштабируемость, стабильность и производительность

В крупных и сверхкрупных развёртываниях vCenter ожидается увеличение числа операций в минуту до 25%. Это касается множества операций с виртуальными машинами и хостами, а также изменений конфигурации. Масштаб одновременных операций резервного копирования ВМ увеличен до 500–1000 в зависимости от размера vCenter. Операции резервного копирования ВМ теперь защищены от бесконтрольного потребления всех ресурсов vCenter. Передача файлов использует выделенные потоки, что исключает влияние на другие операции vCenter. Расширенные параметры vCenter для операций резервного копирования позволяют настраивать масштабируемость под конкретную среду.

Новый API мониторинга утилизации vCenter позволяет отслеживать активные подключения и сравнивать их с максимально допустимыми лимитами. Появилась возможность отслеживать количество запросов ко всем сервисам vCenter и контролировать, чтобы их интенсивность не превышала допустимых порогов.

Введены два новых оповещения — High Session Count и Increased Request Load — для сигнализации о нагрузке на один или несколько сервисов vCenter. Оповещение High Session Count срабатывает, когда число сессий приближается к лимиту (по умолчанию 3000); в сообщении указываются IP-адреса и имена пяти пользователей, создавших наибольшую нагрузку с более чем 100 сессиями каждый. При изменении состава топ-5 пользователей генерируется новое событие. В список могут попасть любые пользователи, включая сервисные аккаунты. Оповещение Increased Request Load срабатывает при достижении лимита активных запросов к конечной точке сервиса (по умолчанию 1024 для большинства конечных точек) и содержит информацию о затронутых сервисах и конечных точках.

Гибкая настройка виртуальных машин

Для поддержки миграции с VMware Cloud Director (vCD) на VMware Cloud Foundation Automation (VCFA) гостевой API настройки ОС (Guest OS Customization, GOSC) дополнен следующими возможностями, обеспечивающими паритет с функциями vCD:

• Установка пароля учётной записи root в Linux
• Сброс пароля учётной записи root в Linux
• Сброс паролей учётных записей группы администраторов в Windows
• Выполнение скриптов настройки в Windows

Теперь администраторы могут явно отключить IPv4 и настроить сеть только для IPv6 в гостевой настройке — как через интерфейс, так и через API. Это устраняет прежнее требование сохранять параллельную конфигурацию IPv4.

Появилась возможность выполнять настройку только сетевых параметров виртуальной машины — для выключенных и для работающих ВМ, что позволяет применять изменения сетевой конфигурации в реальном времени.

Сохранение производительности рабочих нагрузок во время обслуживания хоста

DRS-оптимизированная эвакуация через vMotion (DRS Optimized vMotion Evacuation) гарантирует, что виртуальные машины будут мигрированы с хоста только при наличии достаточной вычислительной ёмкости для их размещения без конкуренции за ресурсы. DRS может предварительно перебалансировать оставшиеся хосты, чтобы создать свободную ёмкость для эвакуируемых ВМ.

При переводе хоста в режим обслуживания для кластеров с включённым DRS доступны два варианта:

Стандартная эвакуация через vMotion: виртуальные машины переносятся на другие хосты в том же кластере при условии совместимости целевых хостов и соответствия требованиям по ресурсам.

Нон-деструктивная эвакуация через vMotion: виртуальные машины переносятся только в том случае, если их текущие вычислительные потребности могут быть удовлетворены целевыми хостами.

Примечание: термин «нон-деструктивная» применительно к новому режиму эвакуации не означает, что стандартная эвакуация как-либо вредит рабочим нагрузкам. Он лишь указывает на то, что при этом режиме эвакуация выполняется только без создания конкуренции за ресурсы на целевых хостах.

Улучшение утилизации ресурсов vMotion и снижение конкуренции

Максимальное количество одновременных задач vMotion по умолчанию равно 8. В предыдущих версиях, если 8 задач vMotion выполнялись одновременно в рамках пакетной операции, новые задачи не начинались до завершения всех предыдущих. Начиная с vSphere 9.1, как только одна задача vMotion завершается и освобождается слот, следующая задача может немедленно стартовать.

Усовершенствованная обработка задач vMotion обеспечивает более равномерное распределение нагрузки по хостам кластера. Число хостов, испытывающих пиковую одновременную нагрузку vMotion, сокращается, а сетевые ресурсы и ресурсы хранилища используются эффективнее.

Более высокая пропускная способность vMotion и сокращение времени миграции

В VCF 9.1 появилась возможность разгрузки операций зашифрованного vMotion на Intel QAT (QuickAssist Technology). Это освобождает ценные ресурсы CPU и возвращает их рабочим нагрузкам.

Для максимально эффективного использования ресурсов в VCF задействована технология Intel QAT (QuickAssist Technology) для ускорения инфраструктурных операций. Перенос «тяжёлой» части задач vMotion на выделенное аппаратное обеспечение позволяет вернуть ценные ядра CPU реальным рабочим нагрузкам. Intel QAT берёт на себя шифрование данных при выполнении операций vMotion.

Оптимизированная масштабируемость и производительность для современных CPU

Планировщик Topology Aware Scheduler перешёл на событийно-ориентированный механизм встроенного обновления, что обеспечивает более согласованное и сбалансированное размещение по NUMA-узлам.

Архитектура NUMA (Non-Uniform Memory Access) используется для повышения масштабируемости и производительности серверов с несколькими процессорными сокетами. Планировщик — компонент ядра ESX, отвечающий за управление размещением виртуальных машин и балансировкой нагрузки по NUMA-узлам с целью минимизации задержек доступа к памяти и оптимального использования ресурсов CPU и памяти рабочими нагрузками.

Topology Aware Scheduler оптимизирован для нового поколения высокоплотных процессоров: улучшена модель оценки эффективности использования CPU и памяти. Существующий планировщик при принятии решений о размещении в основном учитывал конкуренцию за CPU (ready time). Topology Aware Scheduler учитывает не только конкуренцию за CPU, но и конкуренцию за кэш и пропускную способность памяти.

Для систем с асимметричной топологией NUMA, где расстояние между некоторыми парами узлов существенно больше, чем между другими, Topology Aware Scheduler может размещать смежные NUMA-клиенты одной ВМ на подмножестве узлов, расположенных ближе друг к другу.

Готовность к работе с AI-платформами различных производителей

В VCF 9.1 расширена поддержка Enhanced DirectPath I/O.

Речь идёт не просто о «проброске» оборудования, а о его виртуализации — это обеспечивает лучшую утилизацию ресурсов и возможность выполнения операций обслуживания и масштабирования без остановки AI-рабочих нагрузок. Поддержка новых аппаратных устройств в VCF 9.1 открывает доступ ко многим преимуществам виртуализации, включая stun-based операции и быстрое приостановление и возобновление работы. Среди этих преимуществ:

• Storage vMotion
• Снапшоты (включая снапшоты памяти)
• Операции реконфигурации дисков
• Горячее добавление и удаление виртуальных устройств
• ESX Live Patch

ESX 9.1 расширяет свои возможности, внедряя поддержку виртуализации IOMMU для CPU AMD. Теперь администраторы могут задействовать устройства PCI passthrough на системах на базе AMD, повышая производительность и обеспечивая прямой доступ к оборудованию для виртуальных машин.

AMD vIOMMU (Virtual I/O Memory Management Unit) — аппаратно-ускоренная технология, обеспечивающая безопасный высокопроизводительный прямой доступ к памяти (DMA) для виртуальных машин за счёт прямого доступа гостевых систем к регистрам MMIO.

Flow Processing Offload (FPO) и аппаратное направление трафика (hardware steering) повышают эффективность центра обработки данных, перенося обработку сложных сетевых правил с CPU на выделенное аппаратное обеспечение. Это обеспечивает производительность на уровне линейной скорости и быструю масштабируемость виртуализированных сред, освобождая ресурсы CPU для бизнес-приложений.

Enhanced DirectPath I/O поддерживает прямую связь GPU-to-GPU через RDMA over Converged Ethernet (RoCE). Решение предназначено для организаций, выполняющих массивные AI-рабочие нагрузки или высокоскоростную обработку данных: оно обеспечивает производительность, близкую к нативной (необходимую для AI), без отказа от инструментов управления, которые упрощают эксплуатацию виртуализованных ЦОД.

GPU NVIDIA, используемые для vGPU, теперь можно настроить одновременно для тайм-слайсинга и режима MIG, что обеспечивает ещё более эффективное совместное использование ресурсов и повышение плотности.

Функционал vSphere Configuration Profiles помогает администраторам VMware Cloud Foundation управлять настройками ESX-хостов не по отдельности, а на уровне всего кластера. Такой подход удобен, когда нужно не только поддерживать единый стандарт внутри одного кластера, но и переносить уже проверенную конфигурацию в другие кластеры.

Примечание: описанные шаги и интерфейсные элементы относятся к VMware vSphere 9.0.2. В других версиях названия пунктов меню и формулировки могут отличаться.

Что такое vSphere Configuration Profiles

vSphere Configuration Profiles появилась в vSphere 8.0 как развитие идеи Host Profiles для масштабного управления конфигурацией ESX-хостов. В Host Profiles администратору приходилось описывать конфигурацию целиком, что усложняло работу: часто известны только конкретные изменения, которые нужно внести, а не весь полный набор настроек.

В vSphere Configuration Profiles требуется зафиксировать только отличия от конфигурации по умолчанию. Благодаря этому профиль получается более понятным для человека, проще читается и легче поддерживается.

Перенос конфигурации в новые кластеры

Один из типовых сценариев управления конфигурацией — обеспечить одинаковые настройки сразу в нескольких кластерах vSphere. vSphere Configuration Profiles делает такой перенос достаточно прямолинейным: желаемое состояние можно экспортировать из существующего кластера, скорректировать уникальные параметры хостов и затем импортировать в новый кластер.

Совет: конфигурацию можно подготовить для кластера еще до добавления в него ESX-хостов. Для этого нужно заранее знать Host BIOS UUID будущих хостов.

Ниже приведен рабочий процесс копирования конфигурации из одного кластера в другой.

Экспорт конфигурации из существующего кластера

Сначала нужно выгрузить желаемую конфигурацию из уже настроенного кластера. В интерфейсе vSphere следует открыть Cluster, затем Configure, затем Configuration в разделе Desired State. Экспортированный файл будет сохранен в формате JSON.

Внутри JSON находятся как общие для кластера настройки, так и уникальные атрибуты отдельных хостов, например IP-адреса и имена хостов. Минимальная обязательная правка перед переносом — заменить host-specific секцию vSphere Configuration Profile на значения, соответствующие целевому кластеру.

Редактирование JSON-файла vSphere Configuration Profile

Перед импортом полезно понимать структуру JSON-файла профиля. В секции profile > esx находятся настройки, не зависящие от конкретного хоста. Такие параметры можно применить ко всем хостам кластера, поскольку они не содержат уникальных значений для отдельного сервера.

Настройки vSphere Distributed Switch, Port Groups или Datastores могут отличаться от кластера к кластеру, поэтому при необходимости их нужно менять в соответствующих разделах JSON. В демонстрационном сценарии используются те же vSphere Distributed Switch, Port Groups и Datastores, что и в исходном кластере.

Основное внимание при переносе нужно уделить секции host-specific. В показанном примере уникальными значениями для хостов являются IP-адреса трех vmkernel-интерфейсов и имя хоста.

Каждый ESX-хост в host-specific разделе идентифицируется через Host UUID. Этот идентификатор также называют BIOS UUID, поскольку он уникален на уровне аппаратной платформы. В актуальных версиях vSphere и VCF проще всего получить Host UUID через PowerCLI, подключившись к vCenter или напрямую к ESX-хосту.

(Get-VMHost -Name esx-hostname.fqdn).ExtensionData.Hardware.SystemInfo.Uuid

После этого в JSON-файле нужно заменить Host UUID, IP-адреса, маски подсети и имена хостов для каждого сервера целевого кластера. При необходимости хосты можно добавлять или удалять, но важно следить за корректным синтаксисом JSON, особенно за запятыми между элементами.

Импорт обновленной конфигурации в новый кластер

Если целевой кластер еще не создан с включенными vSphere Configuration Profiles или пока не переведен на них, обновленный JSON можно импортировать через workflow перехода на vSphere Configuration Profiles.

Если кластер уже использует vSphere Configuration Profiles, нужно открыть вкладку Draft, выбрать Import From File и загрузить подготовленный JSON-файл.

Затем на вкладке Draft нужно выбрать Apply Changes, чтобы выполнить remediation и применить импортированную конфигурацию. Перед фактическим применением стоит внимательно пройти окна Pre-check, Remediation Settings и Review Impact.

Pre-check проверяет готовность хоста к remediation, включая возможность перевести его в maintenance mode. Также учитывается, включен ли DRS, чтобы при необходимости автоматически эвакуировать виртуальные машины с хоста. Окно Remediation Settings показывает текущие параметры remediation, унаследованные от vSphere Lifecycle Manager.

В окне Review Impact на вкладке Host-Level Details можно раскрыть каждый хост и увидеть, какие именно изменения будут применены. Там же отображается, потребуется ли конкретному хосту переход в maintenance mode.

После проверки влияния изменений остается нажать Remediate, чтобы применить конфигурацию к кластеру.

Итог

vSphere Configuration Profiles позволяет переносить стандартную конфигурацию из одного кластера в другой без ручного повторения всех настроек. Это помогает поддерживать единое желаемое состояние как внутри отдельного кластера, так и между несколькими кластерами vSphere.

Развёртывание Kubernetes в производственной среде требует не просто установки кластера — необходимо с самого начала принять правильные архитектурные решения, от которых будут зависеть масштабируемость, доступность и управляемость платформы. Вебинар специалистов Broadcom Professional Services и MomentumAI посвящён ключевым принципам проектирования VMware vSphere Kubernetes Service (VKS) поверх VMware Cloud Foundation (VCF). Докладчики — Vijay Appani, Solution Architect компании Broadcom, и Caleb Washburn, CTO и основатель MomentumAI — рассматривают проверенные шаблоны проектирования, которые их команды применяют в реальных enterprise-проектах.

Что такое VKS и зачем запускать Kubernetes на VCF

VMware vSphere Kubernetes Service (VKS) — это встроенный механизм запуска Kubernetes на платформе vSphere, интегрированный непосредственно в VMware Cloud Foundation. В отличие от сторонних дистрибутивов, VKS использует подтверждённую CNCF версию Kubernetes и глубоко интегрирован с инфраструктурными компонентами VCF: вычислительным слоем (vSphere), сетью (NSX) и хранилищем (vSAN). Это позволяет организациям строить современную private cloud-платформу, избегая «лоскутных» решений и накапливаемого технического долга.

Ключевая идея заключается в том, что VCF предоставляет единую платформу, объединяющую ресурсы compute, network и storage в согласованный операционный слой. Kubernetes в таком окружении получает доступ к корпоративным политикам хранения, сетевой изоляции на уровне неймспейсов и интеграции с порталом самообслуживания VCF Automation — всё это без необходимости разворачивать и поддерживать внешние инструменты.

Три модели развёртывания Supervisor-кластера

Центральным компонентом VKS является Supervisor-кластер — уровень управления Kubernetes, развёртываемый поверх рабочего домена VCF. Существует три основные топологии его размещения, и выбор между ними определяет поведение платформы при сбоях, требования к ресурсам и сложность эксплуатации.

Модель 1: Single Cluster. Supervisor-кластер и рабочие нагрузки размещаются в одном vSphere-кластере. Это наиболее простой с точки зрения конфигурации вариант. Он подходит для начального знакомства с платформой или сред разработчиков, однако не обеспечивает разделения плоскости управления и плоскости данных. При сбое кластера теряется и управление, и рабочие нагрузки.

Модель 2: Multi-Cluster с разделёнными зонами. Supervisor-контрольная плоскость развёртывается в отдельном управляющем домене, а рабочие нагрузки — в выделенных рабочих доменах. Такое разделение обеспечивает независимость управляющего слоя от прикладного, что принципиально важно для инфраструктуры среднего масштаба. Недостатком является необходимость большего числа хостов и более сложная настройка сети и зон.

Модель 3: vSphere Zones (рекомендуется для enterprise). Виртуальные машины управляющей плоскости Supervisor-кластера распределяются по трём vSphere Zones — логическим группам, каждая из которых соответствует отдельному физическому кластеру. Рабочие нагрузки могут совместно использовать те же три зоны или размещаться в выделенных. Платформа выдерживает полный отказ одной зоны без потери доступности — ни управляющий слой, ни приложения не затрагиваются. Данная модель рекомендуется для крупных enterprise-развёртываний, требующих гарантий высокой доступности на уровне инфраструктуры.

Сетевые опции: NSX или VDS

При настройке сети для VKS на VCF доступны два варианта: NSX и vSphere Distributed Switch (VDS). Выбор между ними оказывает существенное влияние на функциональность платформы и возможности автоматизации.

NSX является рекомендованным выбором для любого нового (greenfield) развёртывания VCF. Overlay-сеть на основе Geneve/VXLAN обеспечивает полную изоляцию на уровне неймспейсов, встроенный распределённый файрвол, встроенный балансировщик нагрузки уровней L4 и L7 (NSX Advanced Load Balancer / AVI), а также глубокую интеграцию с VCF Automation. Именно NSX позволяет реализовать портал самообслуживания, где разработчики и команды самостоятельно запрашивают ресурсы, не взаимодействуя напрямую с vSphere-администраторами.

VDS применяется в случаях, когда NSX не может быть развёрнут — например, при модернизации существующей инфраструктуры или при строгих ограничениях лицензирования. VDS поддерживает базовые возможности VKS, однако не поддерживает VCF Automation, overlay-сети и встроенный балансировщик нагрузки. При использовании VDS в производственной среде потребуется внешний балансировщик, что добавляет операционную сложность.

Отдельно подчёркивается, что если требования к приложению предполагают L4 или L7 балансировку, использование выделенного балансировщика нагрузки является обязательным — независимо от выбранного сетевого варианта.

Хранилище: vSAN, политики и управление томами

Хранилище в архитектуре VKS разделяется на два типа: эфемерное (ephemeral) и постоянное (persistent). Эфемерное хранилище используется для дисков самих узлов Kubernetes (Control Plane VMs и Worker Nodes) и временных томов Pod'ов. Оно берётся из основного или дополнительного хранилища рабочего домена и настраивается при активации Supervisor-кластера.

Постоянные тома (Persistent Volumes, PV) предназначены для stateful-приложений — баз данных, очередей сообщений, систем хранения состояния. Доступ к постоянному хранилищу управляется через Storage Policies — политики хранения vSAN, которые администратор создаёт в vCenter. Политики описывают параметры производительности, доступности (RAID-1, RAID-5/6) и шифрования. Каждый арендатор (tenant) в мультитенантной конфигурации получает доступ только к тем политикам хранения, которые ему явно назначены.

Если арендатору не назначена ни одна storage policy, он не сможет создавать Persistent Volume Claims (PVC) — это удобный механизм ограничения: организации могут предоставлять namespace без прав на stateful-хранение там, где это нежелательно. Поддерживаются режимы доступа RWO (ReadWriteOnce) и RWX (ReadWriteMany) — последний обычно требует дополнительных компонентов типа vSAN File Services или внешних NFS-решений.

Мультитенантность и интеграция с VCF Automation

Одним из ключевых преимуществ VKS на VCF является встроенная поддержка мультитенантности через механизм namespace и интеграцию с VCF Automation. Каждый неймспейс представляет собой изолированную рабочую область, которой могут быть назначены: квоты на CPU и RAM, доступные storage policies, сетевые профили NSX, а также права доступа пользователей или групп из Active Directory / LDAP.

VCF Automation предоставляет портал самообслуживания, через который подразделения и команды разработчиков могут самостоятельно запрашивать Kubernetes namespace, инициировать развёртывание приложений и управлять ресурсами — без участия администратора vSphere. Платформа автоматически создаёт необходимые ресурсы: сетевые сегменты NSX, политики хранения, RBAC-права. Это, по словам авторов вебинара, является «новейшим и наиболее зрелым способом организации современного private cloud».

Рекомендуется начинать с NSX в качестве сетевого стека при любом новом greenfield-развёртывании VCF именно потому, что VCF Automation поддерживает только NSX, и без него модель самообслуживания недоступна.

Рекомендации по проектированию production-платформы

По итогам вебинара сформулированы следующие практические рекомендации для команд, проектирующих VKS на VCF в производственной среде:

• Используйте топологию vSphere Zones для любого развёртывания с требованиями к высокой доступности — она обеспечивает автоматический failover при отказе целого кластера без вмешательства администратора.
• Выбирайте NSX как сетевой стек при greenfield-развёртывании — только с NSX доступна полная интеграция с VCF Automation и портал самообслуживания.
• Планируйте storage policies заранее: определите требования к производительности и отказоустойчивости для разных классов рабочих нагрузок ещё до запуска первых неймспейсов.
• Разграничивайте доступ к хранилищу на уровне арендаторов — не назначайте storage policies тем неймспейсам, которым stateful-хранение не нужно.
• Если среда требует L4/L7 балансировки, включайте NSX Advanced Load Balancer (AVI) в архитектуру с самого начала — добавить его позднее значительно сложнее.
• Не смешивайте управляющую и рабочую плоскости в одном кластере для производственной среды: выделяйте отдельный рабочий домен для приложений, даже если это требует дополнительных хостов.

Вопросы и ответы: ключевые моменты

В ходе сессии вопросов и ответов слушателей интересовали несколько практических аспектов. На вопрос о поддержке собственных сервисов поверх VKS ответ был однозначным: технически это возможно, однако рекомендуется использовать интегрированный стек — vSAN, NSX и VCF Automation — поскольку именно на нём строится поддержка и будущее развитие платформы.

На вопрос об источниках эфемерного хранилища пояснялось, что при активации Supervisor-кластера администратор указывает datastore, из которого берётся эфемерное хранилище для узлов Kubernetes и временных томов Pod'ов. Это может быть как vSAN, так и дополнительное (supplemental) хранилище рабочего домена.

Относительно нестандартных конфигураций — в частности, развёртывания VKS поверх существующей vSphere-среды без полного стека VCF — авторы отметили, что такие варианты существуют, но лишены ключевых преимуществ интегрированной платформы: автоматизации, самообслуживания и единого управления жизненным циклом.

Итог

VMware vSphere Kubernetes Service на VMware Cloud Foundation представляет собой зрелую enterprise-платформу для запуска production-Kubernetes с полной интеграцией в корпоративную инфраструктуру. Правильный выбор топологии Supervisor-кластера, сетевого стека и модели хранения на этапе проектирования определяет, насколько легко платформа будет масштабироваться и насколько просто её будет эксплуатировать в долгосрочной перспективе. Ознакомиться с предстоящими вебинарами серии VCF можно по ссылке go-vmware.broadcom.com/VCFWebinars.

Многие VMware-инфраструктуры сегодня находятся в переходной стадии: организации продолжают использовать vSphere-кластеры, но постепенно переходят к модели Software-Defined Data Center и частного облака на базе VMware Cloud Foundation (VCF). Полностью перестраивать инфраструктуру с нуля в производственной среде обычно невозможно. Там уже работают десятки или сотни виртуальных машин, поэтому перенос на новую платформу должен происходить максимально аккуратно. Именно для таких сценариев VMware предлагает механизм Brownfield-интеграции.

Этот подход позволяет смигрировать существующую инфраструктуру vSphere на VMware Cloud Foundation без переустановки среды и без миграции виртуальных машин. Подробно этот процесс рассмотрел Tarsio Moraes в своем видео:

Что такое Brownfield-апгрейд

Brownfield-подход означает интеграцию уже существующей инфраструктуры в новую платформу без полного развертывания новой среды. В VMware-экосистеме это означает, что существующий vCenter Server, кластеры ESX и запущенные виртуальные машины могут быть импортированы в VCF как отдельный Workload Domain.

Таким образом инфраструктура сохраняет текущие рабочие нагрузки, но получает централизованное управление, автоматизированное lifecycle-обновление и интеграцию сетевой платформы NSX.

Архитектура до и после интеграции

Исходная инфраструктура

Типичная среда включает vSphere 8, один или несколько кластеров ESXi, vCenter Server и систему хранения — например vSAN или внешние датасторы. Сетевая конфигурация обычно построена на распределенном коммутаторе Distributed Switch. В такой архитектуре управление вычислениями, сетью и мониторингом может осуществляться через разные инструменты.

После интеграции в VCF

После импорта инфраструктура становится частью платформы VMware Cloud Foundation. Появляется централизованное управление через компоненты VCF, а инфраструктура разделяется на management domain и workload domains. Также стоит учитывать изменения в продуктовой линейке VMware: многие функции бывшей линейки Aria теперь встроены непосредственно в VMware Cloud Foundation (как функционал модуля Operations).

Подготовка инфраструктуры

Перед запуском Brownfield-апгрейда необходимо убедиться, что инфраструктура соответствует требованиям совместимости. В первую очередь проверяются версии компонентов: vSphere, vCenter Server и ESXi (теперь он снова называется ESX). Кроме того, важно убедиться в совместимости оборудования через VMware Compatibility Guide.

Также необходимо проверить базовые инфраструктурные сервисы: DNS, NTP, доступность сетей управления и состояние датасторов. Особенно важно убедиться, что DNS корректно разрешает имена хостов ESX, vCenter и будущих узлов NSX Manager.

Подготовка среды управления

Перед импортом vSphere-среды необходимо подготовить управляющие компоненты VMware Cloud Foundation. К ним относятся VCF Fleet Management и VCF Operations. Эти сервисы отвечают за централизованное управление инфраструктурой, мониторинг и lifecycle-операции. На этом этапе стоит проверить доступность management-компонентов, валидность сертификатов и сетевую связность между сервисами управления и vCenter.

Использование VCF Import Tool

Для интеграции существующей среды используется специальный инструмент — VCF Import Tool. Он анализирует конфигурацию vSphere, выполняет проверку совместимости и подготавливает инфраструктуру к импорту. Перед запуском процесса выполняется серия pre-check проверок, которые анализируют сеть, лицензии, сертификаты, конфигурацию кластеров и параметры хранения.

Если обнаружены ошибки или предупреждения, их необходимо устранить до начала импорта.

Импорт vCenter как Workload Domain

После завершения подготовительных этапов можно приступать к импорту существующего vCenter. В интерфейсе VCF создаётся новый workload domain, после чего указываются параметры подключения к существующему vCenter. После проверки параметров запускается автоматический рабочий процесс (workflow), который выполняет регистрацию vCenter в инфраструктуре VCF.

С этого момента среда становится частью VMware Cloud Foundation.

Развертывание NSX

Следующий этап — интеграция сетевой платформы NSX. Если NSX ранее не использовался, VMware Cloud Foundation может автоматически развернуть NSX Manager cluster и подготовить хосты ESX. Если NSX уже установлен в инфраструктуре, он может быть импортирован вместе с workload domain.

Пост-апгрейд проверки

После завершения интеграции необходимо провести проверку состояния среды. Стоит убедиться, что workload domain корректно отображается в интерфейсе VCF, хосты ESX подключены, датасторы доступны, а виртуальные машины работают без ошибок.

Дополнительно рекомендуется протестировать ключевые операции виртуализации: vMotion, создание снапшота и сетевую связность между виртуальными машинами.

Итог

Brownfield-апгрейд позволяет перевести существующую инфраструктуру vSphere 8 в модель VMware Cloud Foundation 9 без полного перестроения среды. Этот подход сохраняет текущие рабочие нагрузки, централизует управление инфраструктурой и позволяет постепенно перейти к архитектуре частного облака.

VMware vSphere 7 достигнет конца основного срока поддержки (End of General Support) 2 октября 2025 года. Если вы в настоящее время используете vSphere 7, вам необходимо перейти на vSphere 8, чтобы продолжать получать поддержку продукта, обновления безопасности и патчи. Это также подготовит вас к переходу на VCF 9, когда вы будете к этому готовы.

Существует два варианта обновления:

1. Вы можете напрямую обновить vSphere 7 до vSphere 8

2. Либо можно импортировать vSphere 7 в VMware Cloud Foundation (VCF) версии 5.2 и выполнить обновление домена рабочих нагрузок до версии 8 через VMware SDDC Manager.

Выбор подходящего пути зависит от ряда факторов, таких как готовность бизнеса, поддержка сторонних продуктов и конфигурация среды. Ниже описано, как команда VCF Professional Services подходит к каждому из этих вариантов.

Вариант 1: Обновление с использованием vSphere Lifecycle Manager

Этот вариант представляет собой традиционный способ обновления vSphere. Вы можете использовать vSphere Lifecycle Manager Images или vSphere Lifecycle Manager Baselines для выполнения задачи обновления.

Преимущества этого подхода:

• Используются уже существующие операционные процессы обновления.
• В большинстве случаев требуется минимальное изменение текущей среды.
• Нет необходимости в дополнительных виртуальных модулях (appliances).

Недостатки этого подхода:

• Вам необходимо вручную выполнять проверки совместимости и валидации между компонентами, что может занять много времени.
• Каждая среда проектируется отдельно, что может привести к задержкам из-за различных архитектурных решений между экземплярами VMware vCenter.

Шаги по обновлению с использованием vSphere Lifecycle Manager

Многие организации сначала выполняют обновление на тестовой (staging) среде перед тем, как переходить к рабочей (production). Шаги, как правило, одинаковы для любых сред.

Шаг 1: Планирование, предварительная проверка и подготовка среды к обновлению.

На этом этапе необходимо вручную подтвердить, что ваша среда поддерживает новые версии. Начните с изучения Release Notes для vSphere 8 и проверьте, поддерживают ли ваши интеграции с другими продуктами VMware или сторонними приложениями vSphere 8. Также потребуется подготовка к обновлению vCenter и понимание изменений, связанных с обновлением хостов VMware ESX.

Шаг 2: Загрузка бинарных файлов (если необходимо).

После планирования нужно загрузить необходимые бинарные файлы. Это можно сделать на сайте поддержки Broadcom.

Шаг 3: Обновление vCenter.

Обновление vCenter можно выполнить несколькими способами, в зависимости от требований пользователя. Существует три основных метода:

• Обновление с сокращённым временем простоя (Reduced Downtime Upgrade) - при этом способе разворачивается вторичный виртуальный модуль, и конфигурационные данные переносятся на него. Это наиболее предпочтительный метод, поскольку он обеспечивает минимальные простои по сравнению с другими способами обновления.

• Установщик vCenter (vCenter Installer) – установщик vCenter включает опцию обновления, которая позволяет обновить существующий виртуальный модуль. Этот метод может быть использован в случае, если недостаточно ресурсов для развертывания второго модуля.

• Обновление через интерфейс управления виртуальным модулем (Virtual Appliance Management Interface Upgrade) – этот метод позволяет автоматически загрузить и установить бинарные файлы напрямую из интерфейса управления виртуальным модулем vCenter. Мы также можем использовать этот способ, если недостаточно ресурсов для развертывания второго модуля.

Шаг 4: Обновление хостов ESX.

После обновления vCenter можно переходить к обновлению хостов ESX. Существует несколько способов обновления хостов ESX. VMware использует два основных подхода:

• vSphere Lifecycle Manager - это предпочтительный метод, так как он позволяет обновлять целые кластеры одновременно, вместо обновления каждого хоста по отдельности. Это самый простой способ выполнения обновлений.

• Сценарные обновления (Scripted Upgrades) – этот метод рекомендуется, когда необходимо обновить большое количество хостов. Существует несколько способов автоматизации обновления с помощью сценариев, что позволяет адаптировать процесс под конкретные операционные процедуры и используемые языки скриптов.

Шаг 5: Обновление VMware vSAN.

После обновления хостов следующим шагом является обновление формата дисков vSAN. Этот шаг рекомендуется, но не является обязательным. Обновление vSAN позволяет воспользоваться новыми функциями.

Шаг 6: Обновление версии vSphere Distributed Switch.

Версию vSphere Distributed Switch также можно обновить. Этот шаг также является необязательным, однако рекомендуется его выполнить, чтобы получить доступ к новым возможностям.

Шаг 7: Проверка после обновления (Post-Upgrade Validation).

Этот шаг зависит от конкретной среды и может включать дополнительные обновления других компонентов для поддержки новой версии. Кроме того, вам потребуется ввести новые лицензии и выполнить все необходимые проверки.

На этом процесс обновления среды vSphere с использованием vSphere Lifecycle Manager завершается.

Вариант 2: Импорт vSphere в экземпляр VCF и обновление через SDDC Manager

Второй вариант — это импорт среды vSphere в VCF 5.2 с последующим обновлением через консоль SDDC Manager. Для этого у вас уже должен быть развернут экземпляр VCF.

Преимущества импорта vSphere в VCF и обновления через SDDC Manager:

• VCF включает в себя мощный механизм проверки предварительных условий, что упрощает процесс обновления.
• При импорте vSphere в VCF ваша среда проверяется, и определяются необходимые исправления, чтобы привести её в соответствие со стандартной архитектурой VCF.
• Вы можете воспользоваться другими возможностями VCF, такими как встроенное управление сертификатами и паролями. Эти функции ускоряют процесс обновления, позволяя легко изменять пароли и сертификаты.

Недостатки:

• Требуются дополнительные виртуальные модули. VCF представляет собой полноценный программно-определяемый датацентр, и такие компоненты, как VMware NSX, являются обязательными. Это требует выделения дополнительных ресурсов.
• Как упомянуто в разделе с преимуществами, приведение среды к стандарту VCF может потребовать выполнения определённых исправлений.

Шаги по импорту vSphere в VCF и обновлению через SDDC Manager

Шаг 1: Импорт существующей среды vSphere в конфигурацию VCF.

Используйте VCF Import Tool для проверки предварительных условий и выполнения импорта в уже существующий экземпляр VCF.

Шаг 2: Обновление vSphere через SDDC Manager.

После того как в среде доступен SDDC Manager, вы можете использовать его для выполнения следующих задач:

• Загрузка пакетов обновлений (Download Update Bundles) – скачайте необходимые пакеты, чтобы иметь возможность выполнить обновление.

• Выполнение предварительных проверок (prechecks) – выполните проверку предварительных условий, чтобы выявить проблемы, которые могут привести к сбою обновления. Если будут обнаружены какие-либо ошибки или проблемы, их необходимо устранить перед продолжением процесса.

• Обновление компонентов (Upgrade Components) – обновите все компоненты vSphere (vCenter и ESX). SDDC Manager выполнит обновление в правильной последовательности, чтобы обеспечить совместимость с перечнем компонентов (Bill of Materials) VCF 5.2.

Шаг 3: Проверка после обновления (Post-Upgrade Validation).

Этот шаг зависит от конкретной среды и может потребовать дополнительных обновлений других компонентов для поддержки новой версии. Кроме того, потребуется ввести новые лицензии и выполнить все необходимые проверки.

Как уже упоминалось, данный вариант требует наличия развернутого экземпляра VCF. Если его нет, вы можете сначала обновить хотя бы один экземпляр vCenter 7 до vSphere 8, используя Вариант 1, а затем преобразовать этот экземпляр vSphere в VCF.

Новая версия платформы VMware Cloud Foundation 9.0, включающая компоненты виртуализации серверов и хранилищ VMware vSphere 9.0, а также виртуализации сетей VMware NSX 9, привносит не только множество улучшений, но и устраняет ряд устаревших технологий и функций. Многие возможности, присутствовавшие в предыдущих релизах ESX (ранее ESXi), vCenter и NSX, в VCF 9 объявлены устаревшими (deprecated) или полностью удалены (removed). Это сделано для упрощения архитектуры, повышения безопасности и перехода на новые подходы к архитектуре частных и публичных облаков. Ниже мы подробно рассмотрим, каких функций больше нет во vSphere 9 (в компонентах ESX и vCenter) и NSX 9, и какие альтернативы или рекомендации по миграции существуют для администраторов и архитекторов.

Почему важно знать об удалённых функциях?

Новые релизы часто сопровождаются уведомлениями об устаревании и окончании поддержки прежних возможностей. Игнорирование этих изменений может привести к проблемам при обновлении и эксплуатации. Поэтому до перехода на VCF 9 следует проанализировать, используете ли вы какие-либо из перечисленных ниже функций, и заранее спланировать отказ от них или переход на новые инструменты.

VMware vSphere 9: удалённые и устаревшие функции ESX и vCenter

В VMware vSphere 9.0 (гипервизор ESX 9.0 и сервер управления vCenter Server 9.0) прекращена поддержка ряда старых средств администрирования и внедрены новые подходы. Ниже перечислены основные функции, устаревшие (подлежащие удалению в будущих версиях) или удалённые уже в версии 9, а также рекомендации по переходу на современные альтернативы:

• vSphere Auto Deploy (устарела) – сервис автоматического развертывания ESXi-хостов по сети (PXE-boot) объявлен устаревшим. В ESX 9.0 возможность Auto Deploy (в связке с Host Profiles) будет удалена в одном из следующих выпусков линейки 9.x.
  
  Рекомендация: если вы использовали Auto Deploy для бездискового развёртывания хостов, начните планировать переход на установку ESXi на локальные диски либо использование скриптов для автоматизации установки. В дальнейшем управление конфигурацией хостов следует осуществлять через образы vLCM и vSphere Configuration Profiles, а не через загрузку по сети.

• vSphere Host Profiles (устарела) – механизм профилей хоста, позволявший применять единые настройки ко многим ESXi, будет заменён новой системой конфигураций. Начиная с vCenter 9.0, функциональность Host Profiles объявлена устаревшей и будет полностью удалена в будущих версиях.
  
  Рекомендация: вместо Host Profiles используйте vSphere Configuration Profiles, позволяющие управлять настройками на уровне кластера. Новый подход интегрирован с жизненным циклом vLCM и обеспечит более надежную и простую поддержку конфигураций.

• vSphere ESX Image Builder (устарела) – инструмент для создания кастомных образов ESXi (добавления драйверов и VIB-пакетов) больше не развивается. Функциональность Image Builder фактически поглощена возможностями vSphere Lifecycle Manager (vLCM): в vSphere 9 вы можете создавать библиотеку образов ESX на уровне vCenter и собирать желаемый образ из компонентов (драйверов, надстроек от вендоров и т.д.) прямо в vCenter.
  
  Рекомендация: для формирования образов ESXi используйте vLCM Desired State Images и новую функцию ESX Image Library в vCenter 9, которая позволит единообразно управлять образами для кластеров вместо ручной сборки ISO-файлов.

• vSphere Virtual Volumes (vVols, устарела) – технология виртуальных томов хранения объявлена устаревшей с выпуском VCF 9.0 / vSphere 9.0. Поддержка vVols отныне будет осуществляться только для критических исправлений в vSphere 8.x (VCF 5.x) до конца их поддержки. В VCF/VVF 9.1 функциональность vVols планируется полностью удалить.
  
  Рекомендация: если в вашей инфраструктуре используются хранилища на основе vVols, следует подготовиться к миграции виртуальных машин на альтернативные хранилища. Предпочтительно задействовать VMFS или vSAN, либо проверить у вашего поставщика СХД доступность поддержки vVols в VCF 9.0 (в индивидуальном порядке возможна ограниченная поддержка, по согласованию с Broadcom). В долгосрочной перспективе стратегия VMware явно смещается в сторону vSAN и NVMe, поэтому использование vVols нужно минимизировать.

• vCenter Enhanced Linked Mode (устарела) – расширенный связанный режим vCenter (ELM), позволявший объединять несколько vCenter Server в единый домен SSO с общей консолью, более не используется во VCF 9. В vCenter 9.0 ELM объявлен устаревшим и будет удалён в будущих версиях. Хотя поддержка ELM сохраняется в версии 9 для возможности обновления существующих инфраструктур, сама архитектура VCF 9 переходит на иной подход: единое управление несколькими vCenter осуществляется средствами VCF Operations вместо связанного режима.
  
  Рекомендация: при планировании VCF 9 откажитесь от развёртывания новых связанных групп vCenter. После обновления до версии 9 рассмотрите перевод существующих vCenter из ELM в раздельный режим с группированием через VCF Operations (который обеспечивает центральное управление без традиционного ELM). Функции, ранее обеспечивавшиеся ELM (единый SSO, объединённые роли, синхронизация тегов, общая точка API и пр.), теперь достигаются за счёт возможностей VCF Operations и связанных сервисов.

• vSphere Clustering Service (vCLS, устарела) – встроенный сервис кластеризации, который с vSphere 7 U1 запускал небольшие служебные ВМ (vCLS VMs) для поддержки DRS и HA, в vSphere 9 более не нужен. В vCenter 9.0 сервис vCLS помечен устаревшим и подлежит удалению в будущем. Кластеры vSphere 9 могут работать без этих вспомогательных ВМ: после обновления появится возможность включить Retreat Mode и отключить развёртывание vCLS-агентов без какого-либо ущерба для функциональности DRS/HA.
  
  Рекомендация: отключите vCLS на кластерах vSphere 9 (включив режим Retreat Mode в настройках кластера) – деактивация vCLS никак не влияет на работу DRS и HA. Внутри ESX 9 реализовано распределенное хранилище состояния кластера (embedded key-value store) непосредственно на хостах, благодаря чему кластер может сохранять и восстанавливать свою конфигурацию без внешних вспомогательных ВМ. В результате вы упростите окружение (больше никаких «мусорных» служебных ВМ) и избавитесь от связанных с ними накладных расходов.

• ESX Host Cache (устарела) - в версии ESX 9.0 использование кэша на уровне хоста (SSD) в качестве кэша с обратной записью (write-back) для файлов подкачки виртуальных машин (swap) объявлено устаревшим и будет удалено в одной из будущих версий. В качестве альтернативы предлагается использовать механизм многоуровневой памяти (Memory Tiering) на базе NVMe. Memory Tiering с NVMe позволяет увеличить объём доступной оперативной памяти на хосте и интеллектуально распределять память виртуальной машины между быстрой динамической оперативной памятью (DRAM) и NVMe-накопителем на хосте.
  
  Рекомендация: используйте функции Advanced Memory Tiering на базе NVMe-устройств в качестве второго уровня памяти. Это позволяет увеличить объём доступной памяти до 4 раз, задействуя при этом существующие слоты сервера для недорогого оборудования.
  
  
• Память Intel Optane Persistent Memory (удалена) - в версии ESX 9.0 прекращена поддержка технологии Intel Optane Persistent Memory (PMEM). Для выбора альтернативных решений обратитесь к представителям вашего OEM-поставщика серверного оборудования.
  
  Рекомендация: в качестве альтернативы вы можете использовать функционал многоуровневой памяти (Memory Tiering), официально представленный в ESX 9.0. Эта технология позволяет добавлять локальные NVMe-устройства на хост ESX в качестве дополнительного уровня памяти. Дополнительные подробности смотрите в статье базы знаний VMware KB 326910.
  
  
• Технология Storage I/O Control (SIOC) и балансировщик нагрузки Storage DRS (удалены) - в версии vCenter 9.0 прекращена поддержка балансировщика нагрузки Storage DRS (SDRS) на основе ввода-вывода (I/O Load Balancer), балансировщика SDRS на основе резервирования ввода-вывода (SDRS I/O Reservations-based load balancer), а также компонента vSphere Storage I/O Control (SIOC). Эти функции продолжают поддерживаться в текущих релизах 8.x и 7.x. Удаление указанных компонентов затрагивает балансировку нагрузки на основе задержек ввода-вывода (I/O latency-based load balancing) и балансировку на основе резервирования ввода-вывода (I/O reservations-based load balancing) между хранилищами данных (datastores), входящими в кластер хранилищ Storage DRS. Кроме того, прекращена поддержка активации функции Storage I/O Control (SIOC) на отдельном хранилище и настройки резервирования (Reservations) и долей (Shares) с помощью политик хранения SPBM Storage Policy. При этом первоначальное размещение виртуальных машин с помощью Storage DRS (initial placement), а также балансировка нагрузки на основе свободного пространства и политик SPBM Storage Policy (для лимитов) не затронуты и продолжают работать в vCenter 9.0.
  
  Рекомендация: администраторам рекомендуется нужно перейти на балансировку нагрузки на основе свободного пространства и политик SPBM. Настройки резервирований и долей ввода-вывода (Reservations, Shares) через SPBM следует заменить альтернативными механизмами контроля производительности со стороны используемых систем хранения (например, встроенными функциями QoS). После миграции необходимо обеспечить мониторинг производительности, чтобы своевременно устранять возможные проблемы.
  
  
• vSphere Lifecycle Manager Baselines (удалена) – классический режим управления патчами через базовые уровни (baselines) в vSphere 9 не поддерживается. Начиная с vCenter 9.0 полностью удалён функционал VUM/vLCM Baselines – все кластеры и хосты должны использовать только рабочий процесс управления жизненным циклом на базе образов (image-based lifecycle). При обновлении с vSphere 8 имеющиеся кластеры на baselines придётся перевести на работу с образами, прежде чем поднять их до ESX 9.
  
  Рекомендация: перейдите от использования устаревших базовых уровней к vLCM images – желаемым образам кластера. vSphere 9 позволяет применять один образ к нескольким кластерам или хостам сразу, управлять соответствием (compliance) и обновлениями на глобальном уровне. Это упростит администрирование и устранит необходимость в ручном создании и применении множества baseline-профилей.
  
  
• Integrated Windows Authentication (IWA, удалена) – в vCenter 9.0 прекращена поддержка интегрированной Windows-аутентификации (прямого добавления vCenter в домен AD). Вместо IWA следует использовать LDAP(S) или федерацию. VMware официально заявляет, что vCenter 9.0 более не поддерживает IWA, и для обеспечения безопасного доступа необходимо мигрировать учетные записи на Active Directory over LDAPS или настроить федерацию (например, через ADFS) с многофакторной аутентификацией.
  
  Рекомендация: до обновления vCenter отключите IWA, переведите интеграцию с AD на LDAP(S), либо настройте VMware Identity Federation с MFA (эта возможность появилась начиная с vSphere 7). Это позволит сохранить доменную интеграцию vCenter в безопасном режиме после перехода на версию 9.
  
  
• Локализации интерфейса (сокращены) – В vSphere 9 уменьшено число поддерживаемых языков веб-интерфейса. Если ранее vCenter поддерживал множество языковых пакетов, то в версии 9 оставлены лишь английский (US) и три локали: японский, испанский и французский. Все остальные языки (включая русский) более недоступны.
  
  Рекомендация: администраторы, использующие интерфейс vSphere Client на других языках, должны быть готовы работать на английском либо на одной из трёх оставшихся локалей. Учебные материалы и документацию стоит ориентировать на английскую версию интерфейса, чтобы избежать недопонимания.

Общий совет по миграции для vSphere: заранее инвентаризуйте использование перечисленных функций в вашей инфраструктуре. Переход на vSphere 9 – удобный повод внедрить новые подходы: заменить Host Profiles на Configuration Profiles, перейти от VUM-бейзлайнов к образам, отказаться от ELM в пользу новых средств управления и т.д. Благодаря этому обновление пройдет более гладко, а ваша платформа будет соответствовать современным рекомендациям VMware.

Мы привели, конечно же, список только самых важных функций VMware vSphere 9, которые подверглись устареванию или удалению, для получения полной информации обратитесь к этой статье Broadcom.

VMware NSX 9: Устаревшие и неподдерживаемые функции

VMware NSX 9.0 (ранее известный как NSX-T) – компонент виртуализации сети в составе VCF 9 – также претерпел существенные изменения. Новая версия NSX ориентирована на унифицированную работу с VMware Cloud Foundation и отказывается от ряда старых возможностей, особенно связанных с гибкостью поддержки разных платформ. Вот ключевые технологии, не поддерживаемые больше в NSX 9, и как к этому адаптироваться:

• Подключение физических серверов через NSX-Agent (удалено) – В NSX 9.0 больше не поддерживается развёртывание NSX bare-metal agent на физических серверах для включения их в оверлей NSX. Ранее такие агенты позволяли физическим узлам участвовать в логических сегментах NSX (оверлейных сетях). Начиная с версии 9, оверлейная взаимосвязь с физическими серверами не поддерживается – безопасность для физических серверов (DFW) остаётся, а вот L2-overlay connectivity убрана.
  
  Рекомендация: для подключения физических нагрузок к виртуальным сетям NSX теперь следует использовать L2-мосты (bridge) на NSX Edge. VMware прямо рекомендует для новых подключений физических серверов задействовать NSX Edge bridging для обеспечения L2-связности с оверлеем, вместо установки агентов на сами серверы. То есть физические серверы подключаются в VLAN, который бриджится в логический сегмент NSX через Edge Node. Это позволяет интегрировать физическую инфраструктуру с виртуальной без установки NSX компонентов на сами серверы. Если у вас были реализованы bare-metal transport node в старых версиях NSX-T 3.x, их придётся переработать на схему с Edge-бриджами перед обновлением до NSX 9. Примечание: распределённый мост Distributed TGW, появившийся в VCF 9, также может обеспечить выход ВМ напрямую на ToR без Edge-узла, что актуально для продвинутых случаев, но базовый подход – через Edge L2 bridge.

• Виртуальный коммутатор N-VDS на ESXi (удалён) – исторически NSX-T использовала собственный виртуальный коммутатор N-VDS для хостов ESXi и KVM. В NSX 9 эта технология более не применяется для ESX-хостов. Поддержка NSX N-VDS на хостах ESX удалена, начиная с NSX 4.0.0.1 (соответствует VCF 9). Теперь NSX интегрируется только с родным vSphere Distributed Switch (VDS) версии 7.0 и выше. Это означает, что все среды на ESX должны использовать конвергентный коммутатор VDS для работы NSX. N-VDS остаётся лишь в некоторых случаях: на Edge-нодах и для агентов в публичных облаках или на bare-metal Linux (где нет vSphere), но на гипервизорах ESX – больше нет.
  
  Рекомендация: перед обновлением до NSX 9 мигрируйте все транспортные узлы ESXi с N-VDS на VDS. VMware предоставила инструменты миграции host switch (начиная с NSX 3.2) – ими следует воспользоваться, чтобы перевести существующие NSX-T 3.x host transport nodes на использование VDS. После перехода на NSX 9 вы получите более тесную интеграцию сети с vCenter и упростите управление, так как сетевые политики NSX привязываются к стандартному vSphere VDS. Учтите, что NSX 9 требует наличия vCenter для настройки сетей (фактически NSX теперь не работает автономно от vSphere), поэтому планируйте инфраструктуру исходя из этого.

• Поддержка гипервизоров KVM и стороннего OpenStack (удалена) – NSX-T изначально позиционировался как мультигипервизорное решение, поддерживая кроме vSphere также KVM (Linux) и интеграцию с opensource OpenStack. Однако с выходом NSX 4.0 (и NSX 9) стратегия изменилась. NSX 9.0 больше не поддерживает гипервизоры KVM и дистрибутивы OpenStack от сторонних производителей. Поддерживается лишь VMware Integrated OpenStack (VIO) как исключение. Проще говоря, NSX сейчас нацелен исключительно на экосистему VMware.
  
  Рекомендация: если у вас были развёрнуты политики NSX на KVM-хостах или вы использовали NSX-T совместно с не-VMware OpenStack, переход на NSX 9 невозможен без изменения архитектуры. Вам следует либо остаться на старых версиях NSX-T 3.x для таких сценариев, либо заменить сетевую виртуализацию в этих средах на альтернативные решения. В рамках же VCF 9 такая ситуация маловероятна, так как VCF подразумевает vSphere-стек. Таким образом, основное действие – убедиться, что все рабочие нагрузки NSX переведены на vSphere, либо изолировать NSX-T 3.x для специфичных нужд вне VCF. В будущем VMware будет развивать NSX как часть единой платформы, поэтому мультиплатформенные возможности урезаны в пользу оптимизации под vSphere.

• NSX for vSphere (NSX-V) 6.x – не применяется – отдельно стоит упомянуть, что устаревшая платформа NSX-V (NSX 6.x для vSphere) полностью вышла из обращения и не входит в состав VCF 9. Её поддержка VMware прекращена еще в начале 2022 года, и миграция на NSX-T (NSX 4.x) стала обязательной. В VMware Cloud Foundation 4.x и выше NSX-V отсутствует, поэтому для обновления окружения старше VCF 3 потребуется заранее выполнить миграцию сетевой виртуализации на NSX-T.
  
  Рекомендация: если вы ещё используете NSX-V в старых сегментах, необходимо развернуть параллельно NSX 4.x (NSX-T) и перенести сетевые политики и сервисы (можно с помощью утилиты Migration Coordinator, если поддерживается ваша версия). Только после перехода на NSX-T вы сможете обновиться до VCF 9. В новой архитектуре все сетевые функции будут обеспечиваться NSX 9, а NSX-V останется в прошлом.

Подводя итог по NSX: VMware NSX 9 сфокусирован на консолидации функций для частных облаков на базе vSphere. Возможности, выходящие за эти рамки (поддержка разнородных гипервизоров, агенты на физической базе и др.), были убраны ради упрощения и повышения производительности. Администраторам следует заранее учесть эти изменения: перевести сети на VDS, пересмотреть способы подключения физических серверов и убедиться, что все рабочие нагрузки, требующие NSX, работают в поддерживаемой конфигурации. Благодаря этому переход на VCF 9 будет предсказуемым, а новая среда – более унифицированной, безопасной и эффективной. Подготовившись к миграции от устаревших технологий на современные аналоги, вы сможете реализовать преимущества VMware Cloud Foundation 9.0 без длительных простоев и с минимальным риском для работы дата-центра.

Итоги

Большинство приведённых выше изменений официально перечислены в документации Product Support Notes к VMware Cloud Foundation 9.0 для vSphere и NSX. Перед обновлением настоятельно рекомендуется внимательно изучить примечания к выпуску и убедиться, что ни одна из устаревших функций, на которых зависит ваша инфраструктура, не окажется критичной после перехода. Следуя рекомендациям по переходу на новые инструменты (vLCM, Configuration Profiles, Edge Bridge и т.д.), вы обеспечите своей инфраструктуре поддерживаемость и готовность к будущим обновлениям в экосистеме VMware Cloud Foundation.

Итак, наконец-то начинаем рассказывать о новых возможностях платформы виртуализации VMware vSphere 9, которая является основой пакета решений VMware Cloud Foundation 9, о релизе которого компания Broadcom объявила несколько дней назад. Самое интересное - гипервизор теперь опять называется ESX, а не ESXi, который также стал последователем ESX в свое время :)

Управление жизненным циклом

Путь обновления vSphere

vSphere 9.0 поддерживает прямое обновление только с версии vSphere 8.0. Прямое обновление с vSphere 7.0 не поддерживается. vCenter 9.0 не поддерживает управление ESX 7.0 и более ранними версиями. Минимально поддерживаемая версия ESX, которую может обслуживать vCenter 9.0, — это ESX 8.0. Кластеры и отдельные хосты, управляемые на основе baseline-конфигураций (VMware Update Manager, VUM), не поддерживаются в vSphere 9. Кластеры и хосты должны использовать управление жизненным циклом только на основе образов.

Live Patch для большего числа компонентов ESX

Функция Live Patch теперь охватывает больше компонентов образа ESX, включая vmkernel и компоненты NSX. Это увеличивает частоту применения обновлений без перезагрузки. Компоненты NSX, теперь входящие в базовый образ ESX, можно обновлять через Live Patch без перевода хостов в режим обслуживания и без необходимости эвакуировать виртуальные машины.

Компоненты vmkernel, пользовательское пространство, vmx (исполнение виртуальных машин) и NSX теперь могут использовать Live Patch. Службы ESX (например, hostd) могут потребовать перезапуска во время применения Live Patch, что может привести к кратковременному отключению хостов ESX от vCenter. Это ожидаемое поведение и не влияет на работу запущенных виртуальных машин. vSphere Lifecycle Manager сообщает, какие службы или демоны будут перезапущены в рамках устранения уязвимостей через Live Patch. Если Live Patch применяется к среде vmx (исполнение виртуальных машин), запущенные ВМ выполнят быструю приостановку и восстановление (Fast-Suspend-Resume, FSR).

Live Patch совместим с кластерами vSAN. Однако узлы-свидетели vSAN (witness nodes) не поддерживают Live Patch и будут полностью перезагружаться при обновлении. Хосты, использующие TPM и/или DPU-устройства, в настоящее время не совместимы с Live Patch.

Создавайте кластеры по-своему с разным оборудованием

vSphere Lifecycle Manager поддерживает кластеры с оборудованием от разных производителей, а также работу с несколькими менеджерами поддержки оборудования (hardware support managers) в рамках одного кластера. vSAN также поддерживает кластеры с различным оборудованием.

Базовая версия ESX является неизменной для всех дополнительных образов и не может быть настроена. Однако надстройки от производителей (vendor addon), прошивка и компоненты в определении каждого образа могут быть настроены индивидуально для поддержки кластеров с разнородным оборудованием. Каждое дополнительное определение образа может быть связано с уникальным менеджером поддержки оборудования (HSM).

Дополнительные образы можно назначать вручную для подмножества хостов в кластере или автоматически — на основе информации из BIOS, включая значения Vendor, Model, OEM String и Family. Например, можно создать кластер, состоящий из 5 хостов Dell и 5 хостов HPE: хостам Dell можно назначить одно определение образа с надстройкой от Dell и менеджером Dell HSM, а хостам HPE — другое определение образа с надстройкой от HPE и HSM от HPE.

Масштабное управление несколькими образами

Образами vSphere Lifecycle Manager и их привязками к кластерам или хостам можно управлять на глобальном уровне — через vCenter, датацентр или папку. Одно определение образа может применяться к нескольким кластерам и/или отдельным хостам из единого централизованного интерфейса. Проверка на соответствие (Compliance), предварительная проверка (Pre-check), подготовка (Stage) и устранение (Remediation) также могут выполняться на этом же глобальном уровне.

Существующие кластеры и хосты с управлением на основе базовых конфигураций (VUM)

Существующие кластеры и отдельные хосты, работающие на ESX 8.x и использующие управление на основе базовых конфигураций (VUM), могут по-прежнему управляться через vSphere Lifecycle Manager, но для обновления до ESX 9 их необходимо перевести на управление на основе образов. Новые кластеры и хосты не могут использовать управление на основе baseline-конфигураций, даже если они работают на ESX 8. Новые кластеры и хосты автоматически используют управление жизненным циклом на основе образов.

Больше контроля над операциями жизненного цикла кластера

При устранении проблем (remediation) в кластерах теперь доступна новая возможность — применять исправления к подмножеству хостов в виде пакета. Это дополняет уже существующие варианты — обновление всего кластера целиком или одного хоста за раз.

Гибкость при выборе хостов для обновления

Описанные возможности дают клиентам гибкость — можно выбрать, какие хосты обновлять раньше других. Другой пример использования — если в кластере много узлов и обновить все за одно окно обслуживания невозможно, клиенты могут выбирать группы хостов и обновлять их поэтапно в несколько окон обслуживания.

Больше никакой неопределённости при обновлениях и патчах

Механизм рекомендаций vSphere Lifecycle Manager учитывает версию vCenter. Версия vCenter должна быть равной или выше целевой версии ESX. Например, если vCenter работает на версии 9.1, механизм рекомендаций не предложит обновление хостов ESX до 9.2, так как это приведёт к ситуации, где хосты будут иметь более новую версию, чем vCenter — что не поддерживается. vSphere Lifecycle Manager использует матрицу совместимости продуктов Broadcom VMware (Product Interoperability Matrix), чтобы убедиться, что целевой образ ESX совместим с текущей средой и поддерживается.

Упрощённые определения образов кластера

Компоненты vSphere HA и NSX теперь встроены в базовый образ ESX. Это делает управление их жизненным циклом и обеспечением совместимости более прозрачным и надёжным. Компоненты vSphere HA и NSX автоматически обновляются вместе с установкой патчей или обновлений базового образа ESX. Это ускоряет активацию NSX на кластерах vSphere, поскольку VIB-пакеты больше не требуется отдельно загружать и устанавливать через ESX Agent Manager (EAM).

Определение и применение конфигурации NSX для кластеров vSphere с помощью vSphere Configuration Profiles

Теперь появилась интеграция NSX с кластерами, управляемыми через vSphere Configuration Profiles. Профили транспортных узлов NSX (TNP — Transport Node Profiles) применяются с использованием vSphere Configuration Profiles. vSphere Configuration Profiles позволяют применять TNP к кластеру одновременно с другими изменениями конфигурации.

Применение TNP через NSX Manager отключено для кластеров с vSphere Configuration Profiles

Для кластеров, использующих vSphere Configuration Profiles, возможность применять TNP (Transport Node Profile) через NSX Manager отключена. Чтобы применить TNP с помощью vSphere Configuration Profiles, необходимо также задать:

• набор правил брандмауэра с параметром DVFilter=true
• настройку Syslog с параметром remote_host_max_msg_len=4096

Снижение рисков и простоев при обновлении vCenter

Функция Reduced Downtime Update (RDU) поддерживается при использовании установщика на базе CLI. Также доступны RDU API для автоматизации. RDU поддерживает как вручную настроенные топологии vCenter HA, так и любые другие топологии vCenter. RDU является рекомендуемым способом обновления, апгрейда или установки патчей для vCenter 9.0.

Обновление vCenter с использованием RDU можно выполнять через vSphere Client, CLI или API. Интерфейс управления виртуальным устройством (VAMI) и соответствующие API для патчинга также могут использоваться для обновлений без переустановки или миграции, однако при этом потребуется значительное время простоя.

Сетевые настройки целевой виртуальной машины vCenter поддерживают автоматическую конфигурацию, упрощающую передачу данных с исходного vCenter. Эта сеть автоматически настраивается на целевой и исходной виртуальных машинах vCenter с использованием адреса из диапазона Link-Local RFC3927 169.254.0.0/16. Это означает, что не требуется указывать статический IP-адрес или использовать DHCP для временной сети.

Этап переключения (switchover) может выполняться вручную, автоматически или теперь может быть запланирован на конкретную дату и время в будущем.

Управление ресурсами

Масштабирование объема памяти с более низкой стоимостью владения благодаря Memory Tiering с использованием NVMe

Memory Tiering использует устройства NVMe на шине PCIe как второй уровень оперативной памяти, что увеличивает доступный объем памяти на хосте ESX. Memory Tiering на базе NVMe снижает общую стоимость владения (TCO) и повышает плотность размещения виртуальных машин, направляя память ВМ либо на устройства NVMe, либо на более быструю оперативную память DRAM.

Это позволяет увеличить объем доступной памяти и количество рабочих нагрузок, одновременно снижая TCO. Также повышается эффективность использования процессорных ядер и консолидация серверов, что увеличивает плотность размещения рабочих нагрузок.

Функция Memory Tiering теперь доступна в производственной среде. В vSphere 8.0 Update 3 функция Memory Tiering была представлена в режиме технологического превью. Теперь же она стала доступна в режиме GA (General Availability) с выпуском VCF 9.0. Это позволяет использовать локально установленные устройства NVMe на хостах ESX как часть многоуровневой (tiered) памяти.

Повышенное время безотказной работы для AI/ML-нагрузок

Механизм Fast-Suspend-Resume (FSR) теперь работает значительно быстрее для виртуальных машин с поддержкой vGPU. Ранее при использовании двух видеокарт NVIDIA L40 с 48 ГБ памяти каждая, операция FSR занимала около 42 секунд. Теперь — всего около 2 секунд. FSR позволяет использовать Live Patch в кластерах, обрабатывающих задачи генеративного AI (Gen AI), без прерывания работы виртуальных машин.

Передача данных vGPU с высокой пропускной способностью

Канал передачи данных vGPU разработан для перемещения больших объемов данных и построен с использованием нескольких параллельных TCP-соединений и автоматического масштабирования до максимально доступной пропускной способности канала, обеспечивая прирост скорости до 3 раз (с 10 Гбит/с до 30 Гбит/с).

Благодаря использованию концепции "zero copy" количество операций копирования данных сокращается вдвое, устраняя узкое место, связанное с копированием, и дополнительно увеличивая пропускную способность при передаче.

vMotion с предкопированием (pre-copy) — это технология передачи памяти виртуальной машины на другой хост с минимальным временем простоя. Память виртуальной машины (как "холодная", так и "горячая") копируется в несколько проходов пока ВМ ещё работает, что устраняет необходимость полного чекпойнта и передачи всей памяти во время паузы, во время которой случается простой сервисов.

Улучшения в предкопировании холодных данных могут зависеть от характера нагрузки. Например, для задачи генеративного AI с большим объёмом статических данных ожидаемое время приостановки (stun-time) будет примерно:

• ~1 секунда для GPU-нагрузки объёмом 24 ГБ
• ~2 секунды для 48 ГБ
• ~22 секунды для крупной 640 ГБ GPU-нагрузки

Отображение профилей vGPU в vSphere DRS

Технология vGPU позволяет распределять физический GPU между несколькими виртуальными машинами, способствуя максимальному использованию ресурсов видеокарты.
В организациях с большим числом GPU со временем создаётся множество vGPU-профилей. Однако администраторы не могут легко просматривать уже созданные vGPU, что вынуждает их вручную отслеживать профили и их распределение по GPU. Такой ручной процесс отнимает время и снижает эффективность работы администраторов.

Отслеживание использования vGPU-профилей позволяет администраторам просматривать все vGPU во всей инфраструктуре GPU через удобный интерфейс в vCenter, устраняя необходимость ручного учёта vGPU. Это существенно сокращает время, затрачиваемое администраторами на управление ресурсами.

В предыдущих версиях распределение виртуальных машин с vGPU могло приводить к ситуации, при которой ни один из хостов не мог удовлетворить требования нового профиля vGPU. Теперь же администраторы могут резервировать ресурсы GPU для будущего использования. Это позволяет заранее выделить GPU-ресурсы, например, для задач генеративного AI, что помогает избежать проблем с производительностью при развертывании таких приложений. С появлением этой новой функции администраторы смогут резервировать пулы ресурсов под конкретные vGPU-профили заранее, улучшая планирование ресурсов и повышая производительность и операционную эффективность.

Администраторы теперь могут перемещать существующие библиотеки контента на новые хранилища данных (datastore) - OVF/OVA-шаблоны, образы и другие элементы могут быть перенесены. Элементы, хранящиеся в формате VM Template (VMTX), не переносятся в целевой каталог библиотеки контента. Шаблоны виртуальных машин (VM Templates) всегда остаются в своем назначенном хранилище, а в библиотеке контента хранятся только ссылки на них.

Во время миграции библиотека контента перейдёт в режим обслуживания, а после завершения — снова станет активной. На время миграции весь контент библиотеки (за исключением шаблонов ВМ) будет недоступен. Изменения в библиотеке будут заблокированы, синхронизация с подписными библиотеками приостановлена.

Служба виртуальных машин (VM Service) теперь может импортировать виртуальные машины, находящиеся за пределами Supervisor-кластера, и взять их под своё управление.

В vSphere 8 был представлен протокол Unified Data Transport (UDT) для "холодной" миграции дисков, ранее выполнявшейся с использованием NFC. UDT значительно ускоряет холодную миграцию, но вместе с повышенной эффективностью увеличивается и нагрузка на сеть предоставления ресурсов (provisioning network), которая в текущей архитектуре использует общий канал с критически важным трафиком управления.

Чтобы предотвратить деградацию трафика управления, необходимо использовать Network I/O Control (NIOC) — он позволяет гарантировать приоритет управления даже при высокой сетевой нагрузке.

vSphere Distributed Switch 9 добавляет отдельную категорию системного трафика для provisioning, что позволяет применять настройки NIOC и обеспечить баланс между производительностью и стабильностью.

Provisioning/NFC-трафик (включая Network File Copy) является тяжеловесным и низкоприоритетным, но при этом использует ту же категорию трафика, что и управляющий (management), который должен быть легковесным и высокоприоритетным. С учетом того, что трафик provisioning/NFC стал ещё более агрессивным с внедрением NFC SOV (Streaming Over vMotion), вопрос времени, когда критически важный трафик управления начнёт страдать.

Существует договоренность с VCF: как только NIOC для provisioning/NFC будет реализован, можно будет включать NFC SOV в развёртываниях VCF. Это ускорит внедрение NFC SOV в продуктивных средах.

Устройства, которые не могут быть приостановлены (non-stunnable devices), теперь поддерживают Storage vMotion (но не обычный vMotion), а также горячее добавление виртуальных устройств, таких как:

• vCPU
• Память (Memory)
• Сетевые адаптеры (NIC)

Примеры non-stunnable устройств:

• Intel DLB (Dynamic Load Balancer)
• AMD MI200 GPU

Гостевые ОС и рабочие нагрузки

Виртуальное оборудование версии 22 (Virtual Hardware Version 22)

• Увеличен лимит vCPU до 960 на одну виртуальную машину
• Поддержка новейших моделей процессоров от AMD и Intel
• Поддержка новых версий гостевых ОС для развертывания ВМ (см. Guest OS Support в VCF 9.0)

Виртуальный модуль доверенной платформы (vTPM)

• vTPM теперь поддерживает спецификацию TPM 2.0, версия 1.59.
• ESX 9.0 соответствует TPM 2.0 Rev 1.59.
• Это повышает уровень кибербезопасности, когда вы добавляете vTPM-устройство в виртуальную машину с версией 22 виртуального железа.

Новые vAPI для настройки гостевых систем (Guest Customization)

Представлен новый интерфейс CustomizationLive API, который позволяет применять спецификацию настройки (customization spec) к виртуальной машине в работающем состоянии (без выключения). Подробности — в последней документации по vSphere Automation API для VCF 9.0. Также добавлен новый API для настройки гостевых систем, который позволяет определить, можно ли применить настройку к конкретной ВМ, ещё до её применения.

• Namespace Write Protection - позволяет горячее добавление независимых непостоянных (non-persistent) дисков в виртуальную машину без создания дополнительных delta-дисков. Эта функция особенно полезна для рабочих нагрузок, которым требуется быстрое развёртывание приложений.
• Write Zeros - для виртуальных NVMe-дисков улучшает производительность, эффективность хранения данных и дает возможности управления данными для различных типов нагрузок.

Безопасность, соответствие требованиям и отказоустойчивость виртуальных машин

Одним из частых запросов в последние годы была возможность использовать собственные сертификаты Secure Boot для ВМ. Обычно виртуальные машины работают "из коробки" с коммерческими ОС, но некоторые организации используют собственные ядра Linux и внутреннюю PKI-инфраструктуру для их подписи.

Теперь появилась прямая и удобная поддержка такой конфигурации — vSphere предоставляет механизм для загрузки виртуальных машин с кастомными сертификатами Secure Boot.

Обновлён список отозванных сертификатов Secure Boot

VMware обновила стандартный список отозванных сертификатов Secure Boot, поэтому при установке Windows на виртуальную машину с новой версией виртуального оборудования может потребоваться современный установочный образ Windows от Microsoft. Это не критично, но стоит иметь в виду, если установка вдруг не загружается.

Виртуальный USB — отличная функция, но VMware внесла ряд улучшений на основе отчётов исследователей по безопасности. Это ещё один веский аргумент в пользу того, чтобы поддерживать актуальность VMware Tools и версий виртуального оборудования.

Обычно мы стремимся к тому, чтобы снапшот ВМ можно было запустить повторно и обеспечить согласованность при сбое (crash-consistency), то есть чтобы система выглядела как будто питание отключилось. Большинство ОС, СУБД и приложений умеют с этим справляться.

Но в случае цифровой криминалистики и реагирования на инциденты, необходимость перезапускать ВМ заново отпадает — важнее получить снимок, пригодный для анализа в специальных инструментах.

Теперь вы можете создавать собственный профиль EVC (Enhanced vMotion Compatibility), определяя набор CPU- и графических инструкций, общих для всех выбранных хостов. Это решение более гибкое и динамичное, чем стандартные предустановленные профили EVC.

Custom EVC позволяет:

• Указать хосты и/или кластеры, для которых vCenter сам рассчитает максимально возможный общий набор инструкций
• Применять полученный профиль к кластерам или отдельным ВМ

Для работы требуется vCenter 9.0 и поддержка кластеров, содержащих хосты ESX 9.0 или 8.0. Теперь доступно более эффективное использование возможностей CPU при различиях между моделями - можно полнее использовать функции процессоров, даже если модели немного отличаются. Пример: два процессора одного поколения, но разных вариантов:

• CPU-1 содержит функции A, B, D, E, F
• CPU-2 содержит функции B, C, D, E, F
• То есть: CPU-1 поддерживает FEATURE-A, но не FEATURE-C, CPU-2 — наоборот.

Custom EVC позволяет автоматически выбрать максимальный общий набор функций, доступный на всех хостах, исключая несовместимости:

В vSphere 9 появилась новая политика вычислений: «Limit VM placement span plus one host for maintenance» («ограничить размещение ВМ числом хостов плюс один для обслуживания»).

Эта политика упрощает соблюдение лицензионных требований и контроль использования лицензий. Администраторы теперь могут создавать политики на основе тегов, которые жестко ограничивают количество хостов, на которых может запускаться группа ВМ с лицензируемым приложением.

Больше не нужно вручную закреплять ВМ за хостами или создавать отдельные кластеры/хосты. Теперь администратору нужно просто:

1. Знать, сколько лицензий куплено.
2. Знать, на скольких хостах они могут применяться.
3. Создать политику с указанием числа хостов, без выбора конкретных.
4. Применить эту политику к ВМ с нужным тегом.

vSphere сама гарантирует, что такие ВМ смогут запускаться только на разрешённом числе хостов. Всегда учитывается N+1 хост в запас для обслуживания. Ограничение динамическое — не привязано к конкретным хостам.

Полный список новых возможностей VMware vSphere 9 также приведен в Release Notes.

В данной статье описывается, как развернуть дома полноценную лабораторию VMware Cloud Foundation (VCF) на одном физическом компьютере. Мы рассмотрим выбор оптимального оборудования, поэтапную установку всех компонентов VCF (включая ESXi, vCenter, NSX, vSAN и SDDC Manager), разберем архитектуру и взаимодействие компонентов, поделимся лучшими практиками...

С выпуском VMware Cloud Foundation (VCF) 5.2 в июле 2024 года VMware представила инструмент VCF Import Tool — новый интерфейс командной строки (CLI), разработанный для упрощения перехода клиентов к частному облаку. Этот инструмент позволяет быстро расширить возможности управления инвентарем SDDC Manager, такие как управление сертификатами, паролями и жизненным циклом, на ваши существующие развертывания vSphere или vSphere с vSAN. Интеграция управления SDDC Manager с вашей текущей инфраструктурой проходит бесшовно, без влияния на работающие нагрузки, сервер vCenter, API vSphere или процессы управления.

Недавно вышло обновление инструмента VCF Import Tool, которое еще больше упрощает импорт существующей инфраструктуры vSphere в современное частное облако. Последний релиз добавляет поддержку более широкого спектра сред и топологий vSphere, а также снимает некоторые ограничения, существовавшие в предыдущих версиях.

Загрузка последних обновлений

Это обновление доступно в составе выпуска 5.2.1.1 для VCF 5.2.1. Чтобы загрузить обновление, войдите в портал Broadcom Software и в разделе «My Downloads» перейдите в «VMware Cloud Foundation», раскройте пункт «VMware Cloud Foundation 5.2» и выберите «5.2.1». Последняя версия инструмента VCF Import (5.2.1.1) доступна на вкладке «Drivers & Tools», как показано на изображении ниже.

Новые возможности VMware Cloud Foundation Import Tool

Возможность импорта кластеров vSphere с общими vSphere Distributed Switches (VDS)

До этого обновления инструмент VCF Import требовал, чтобы у каждого кластера был выделенный VDS. Это соответствовало рекомендуемой практике изоляции кластеров vSphere и избегания зависимости между ними. Однако многие клиенты предпочитают минимизировать количество VDS в своей среде и часто создают единый VDS, который используется несколькими кластерами. С последним обновлением добавлена поддержка как выделенных, так и общих конфигураций VDS. Это дает клиентам гибкость в выборе топологии развертывания VDS и упрощает импорт существующих рабочих нагрузок в Cloud Foundation.

Поддержка импорта кластеров с включенным LACP

Многие клиенты используют протокол управления агрегацией каналов (Link Aggregation Control Protocol, LACP) на своих физических коммутаторах для объединения каналов. Ранее использование LACP с VCF не поддерживалось. Это обновление добавляет поддержку LACP как для преобразованных, так и для импортированных доменов. Теперь использование LACP больше не является препятствием для переноса инфраструктуры vSphere в Cloud Foundation.

Импорт сред vSphere с использованием смешанных конфигураций vLCM Images и Baselines

При развертывании кластеров vSphere VCF предоставляет возможность выбора между использованием образов vSphere Lifecycle Manager (vLCM) и базовых конфигураций (Baselines). Образы vLCM представляют собой современный подход к обновлению программного обеспечения хостов vSphere, основанный на модели желаемого состояния. Базовые конфигурации следуют традиционному подходу, включающему создание базовых профилей и их привязку к кластерам.

Во время перехода клиентов от традиционного подхода с базовыми конфигурациями к новому подходу с образами vLCM многие используют смешанную конфигурацию, где одни кластеры применяют образы, а другие — базовые профили. Ранее VCF требовал, чтобы все кластеры в инвентаре vCenter использовали один тип vLCM. Последнее обновление устраняет это ограничение, добавляя поддержку смешанных сред, где одни кластеры используют vLCM Images, а другие — vLCM Baselines. Это упрощает переход клиентов на VCF, позволяя импортировать существующую инфраструктуру в частное облако Cloud Foundation без необходимости вносить изменения или модификации.

Ослабление ограничений для vSphere Standard Switches и автономных хостов

Помимо изменений, описанных выше, последнее обновление снимает несколько ограничений, ранее мешавших импортировать некоторые топологии. Это включает:

• Разрешение импорта сред vSphere с использованием стандартных коммутаторов vSphere Standard Switches.
• Поддержку сред vSphere с автономными хостами в инвентаре vCenter.
• Поддержку одноузловых кластеров.

При этом важно отметить, что, несмотря на ослабление ограничений для этих компонентов, каждый экземпляр vCenter должен иметь хотя бы один кластер vSphere, соответствующий минимальным требованиям, изложенным в руководстве по администрированию Cloud Foundation.

В обновлении платформы VMware Cloud Foundation 5.2 был представлен новый инструмент командной строки (CLI), называемый VCF Import Tool, который предназначен для преобразования или импорта существующих сред vSphere, которые в настоящее время не управляются менеджером SDDC, в частное облако VMware Cloud Foundation. Вы можете ознакомиться с демонстрацией работы инструмента импорта VCF в этом 6-минутном видео.

Инструмент импорта VCF позволяет клиентам ускорить переход на современное частное облако, предоставляя возможность быстро внедрить Cloud Foundation непосредственно в существующую инфраструктуру vSphere. Нет необходимости приобретать новое оборудование, проходить сложные этапы развертывания или вручную переносить рабочие нагрузки. Вы просто развертываете менеджер SDDC на существующем кластере vSphere и используете инструмент импорта для преобразования его в частное облако Cloud Foundation.

Импорт вашей существующей инфраструктуры vSphere в частное облако VCF происходит без сбоев, поскольку это прозрачно для работающих рабочих нагрузок. В общих чертах, процесс включает сканирование vCenter для обеспечения совместимости с VCF, а затем регистрацию сервера vCenter и его связанного инвентаря в менеджере SDDC. Зарегистрированные экземпляры сервера vCenter становятся доменами рабочих нагрузок VCF, которые можно централизованно управлять и обновлять через менеджер SDDC как часть частного облака VMware. После добавления в инвентарь Cloud Foundation все доступные операции менеджера SDDC становятся доступны для управления преобразованным или импортированным доменом. Это включает в себя расширение доменов путем добавления новых хостов и кластеров, а также применение обновлений программного обеспечения.

Обзор инструмента импорта VCF

Существует два способа начать работу с инструментом импорта VCF.

Если у вас еще нет развернутого виртуального модуля (Virtual Appliance) менеджера SDDC в вашем датацентре, первый шаг — вручную развернуть экземпляр устройства в существующей среде vSphere. Затем вы используете инструмент импорта VCF для преобразования этой среды в управляющий домен VMware Cloud Foundation.

Если в вашем датацентре уже работает экземпляр менеджера SDDC, просто обновите его до версии VCF 5.2 и используйте его для начала импорта существующих сред vSphere как доменов рабочих нагрузок VI. Обратите внимание, что помимо импорта и преобразования сред vSphere в VCF в качестве доменов рабочих нагрузок, инструмент импорта VCF также может быть использован для развертывания NSX в преобразованном или импортированном домене. Это можно сделать как во время преобразования/импорта, так и в качестве операции «Day-2», выполняемой в любое время после добавления среды в качестве домена рабочих нагрузок. Также в инструменте импорта есть функция синхронизации, которая позволяет управлять расхождением конфигураций между сервером vCenter и менеджером SDDC. Подробнее об этих функциях будет рассказано ниже.

Требования для использования инструмента импорта VCF

Чтобы начать работу с инструментом импорта VCF, необходимо выполнить несколько требований. Эти требования различаются в зависимости от того, преобразуете ли вы существующую среду vSphere в управляющий домен VCF или импортируете существующую среду vSphere как домен виртуальной инфраструктуры (VI). Начнем с рассмотрения требований, уникальных для преобразования управляющего домена VCF. Затем перейдем к требованиям, общим для обоих случаев использования — преобразования и импорта.

Примечание: требования и ограничения, указанные в этой статье, основаны на первоначальном релизе инструмента импорта VCF, доступного с VCF 5.2. Обязательно ознакомьтесь с Release Notes, чтобы узнать, применимы ли эти ограничения к версии VCF, которую вы используете.

Требования для преобразования кластера vSphere в управляющий домен VCF

Для преобразования существующей среды vSphere в управляющий домен VCF необходимо учитывать два основных требования.

• Во-первых, среда vSphere, которую вы хотите преобразовать, должна работать на версии vSphere 8.0 Update 3 или выше. Это относится как к экземпляру сервера vCenter, так и к хостам ESXi. Эта версия vSphere соответствует спецификации (Bill of Materials, BOM) VCF 5.2. Это требование связано, в частности, с тем, что сначала нужно развернуть виртуальный модуль менеджера SDDC в кластере, а версия 5.2 этого устройства требует версий vCenter и ESXi 8.0 Update 3 (или выше).
• Во-вторых, при преобразовании среды vSphere сервер vCenter должен работать в кластере, который будет преобразован. В документации это называется требованием «совместного размещения» сервера vCenter с кластером.

Требования для импорта кластера vSphere в домен VI VCF

Как и при преобразовании в новый управляющий домен, при импорте среды vSphere в домен VI VCF также необходимо учитывать два основных требования.

• Во-первых, поддерживаемые версии vSphere для импорта в качестве домена VI — это vSphere 7.0 Update 3 и выше. Это включает как экземпляр сервера vCenter, так и хосты ESXi. Минимальная версия 7.0 с обновлением 3 соответствует версии vCenter и ESXi, которая входит в спецификацию VCF 4.5 (BOM).
• Во-вторых, при импорте среды vSphere сервер vCenter должен работать либо в кластере, который преобразуется (совместно размещенный), либо в кластере в управляющем домене.

Общие требования при преобразовании и импорте кластеров vSphere

Помимо указанных выше требований, существуют следующие общие требования для преобразования и импорта инфраструктуры vSphere.

• Все хосты внутри кластера vSphere должны быть однородными. Это означает, что все хосты в кластере должны быть одинаковыми по мощности, типу хранилища и конфигурации (pNIC, VDS и т.д.). Конфигурации серверов могут различаться между кластерами, но внутри одного кластера хосты должны быть одинаковыми.
• Кластеры, которые будут преобразованы или импортированы, должны использовать один из трех поддерживаемых типов хранилищ: vSAN, NFS или VMFS на Fibre Channel (FC). Это часто вызывает путаницу, так как при развертывании с нуля (greenfield deployment) с использованием устройства Cloud Builder для управляющего домена требуется всегда использовать vSAN. Учтите, что требование vSAN не применяется к преобразованным управляющим доменам, где можно использовать vSAN, NFS или VMFS на FC.
• При использовании vSAN минимальное количество хостов для управляющего домена всегда составляет четыре. Однако при использовании NFS или VMFS на FC минимальное количество хостов составляет три. Это также отличается от требований при развертывании с нуля с использованием Cloud Builder.
• Режим расширенной связи (Enhanced Linked Mode, ELM) не поддерживается инструментом импорта VCF. Каждый экземпляр сервера vCenter, который будет преобразован или импортирован в качестве домена рабочих нагрузок VCF, должен находиться в собственной доменной структуре SSO. Таким образом, каждый преобразованный или импортированный экземпляр vCenter создаст изолированный домен рабочих нагрузок в VCF. Это может стать проблемой для клиентов, которые привыкли к централизованному управлению своей средой VCF через одну панель управления. Обратите внимание на новые дэшборды мониторинга VCF Operations (ранее Aria Operations), которые могут помочь смягчить это изменение.
• Все кластеры в инвентаре vCenter должны быть настроены с использованием одного или нескольких выделенных vSphere Distributed Switches (VDS). Учтите, что стандартные коммутаторы vSphere (VSS) не поддерживаются. Более того, если в кластере настроен VSS, его необходимо удалить перед импортом кластера. Также важно отметить, что VDS не могут быть общими для нескольких кластеров vSphere.
• В инвентаре vCenter не должно быть отдельных хостов ESXi. Отдельные хосты нужно либо переместить в кластер vSphere, либо удалить из инвентаря vCenter.
• Во всех кластерах должно быть включено полное автоматическое распределение ресурсов (DRS Fully Automated), и на всех хостах должна быть настроена выделенная сеть для vMotion.
• Все адаптеры vmkernel должны иметь статически назначенные IP-адреса. В рамках процесса преобразования/импорта в менеджере SDDC будет создан пул сетей с использованием этих IP-адресов. После завершения импорта эти IP-адреса не должны изменяться, поэтому они должны быть статически назначены.
• Среды vSphere не могут иметь несколько адаптеров vmkernel, настроенных для одного и того же типа трафика.

Значимые ограничения инструмента импорта в VCF 5.2

После указания требований для использования инструмента импорта VCF важно отметить несколько ограничений, связанных с версией VCF 5.2, о которых нужно знать. Имейте в виду, что рабочие процессы импорта VCF включают функцию «проверки», которая сканирует инвентарь vCenter перед попыткой преобразования или импорта. Если обнаруживаются ограничения, процесс будет остановлен.

Следующие топологии не могут быть преобразованы или импортированы с использованием инструмента импорта VCF в версии 5.2:

• Среда vSphere, настроенная с использованием NSX.
• Среды vSphere, настроенные с балансировщиком нагрузки AVI.
• Среды vSphere, настроенные с растянутыми кластерами vSAN Stretched Clusters.
• Среды vSphere, где vSAN настроен только в режиме сжатия (compression-only mode).
• Кластеры vSphere с общими распределенными коммутаторами vSphere (VDS).
• Среды vSphere с включенной контрольной панелью IaaS (ранее vSphere with Tanzu).
• Среды vSphere, настроенные с использованием протокола управления агрегированием каналов (LACP).
• Среды VxRail.

Установка NSX на преобразованные и импортированные домены рабочих нагрузок

При обсуждении ограничений, связанных с инструментом импорта VCF, мы отметили, что нельзя преобразовывать или импортировать кластеры, настроенные для NSX. Однако после того, как домен будет преобразован/импортирован, вы можете использовать инструмент импорта VCF для установки NSX. Вы можете выбрать установку NSX одновременно с преобразованием/импортом или в любое время после этого в рамках операций Day-2.

Одна важная вещь, которую следует помнить при использовании инструмента импорта VCF для установки NSX на преобразованный или импортированный домен рабочих нагрузок, заключается в том, что виртуальные сети и логическая маршрутизация не настраиваются в процессе установки NSX. Инструмент импорта устанавливает NSX и настраивает распределенные группы портов в NSX Manager. Это позволяет начать использовать распределенный межсетевой экран NSX для защиты развернутых рабочих нагрузок. Однако для того, чтобы воспользоваться возможностями виртуальных сетей и логического переключения, предоставляемыми NSX, требуется дополнительная настройка, так как вам нужно вручную настроить туннельные эндпоинты хоста (TEPs).

Использование инструмента импорта VCF для синхронизации изменений с сервером vCenter

Помимо возможности импортировать существующую инфраструктуру vSphere в Cloud Foundation, инструмент импорта также предоставляет функцию синхронизации, которая позволяет обновлять менеджер SDDC с учетом изменений, внесенных в инвентарь сервера vCenter, что помогает поддерживать согласованность и точность всей среды.

При управлении инфраструктурой vSphere, которая является частью частного облака Cloud Foundation, могут возникнуть ситуации, когда вам потребуется внести изменения непосредственно в среду vSphere. В некоторых случаях изменения, сделанные непосредственно в инвентаре vCenter, могут не быть захвачены менеджером SDDC. Если инвентарь менеджера SDDC выйдет из синхронизации с инвентарем vCenter, это может временно заблокировать некоторые рабочие процессы автоматизации. Чтобы избежать этого, вы запускаете инструмент импорта CLI с параметром «sync», чтобы обновить инвентарь менеджера SDDC с учетом изменений, внесенных в конфигурацию vCenter.

На днях компания VMware в составе Broadcom выпустила очередной пакет обновлений своей флагманской платформы виртуализации - VMware vSphere 8.0 Update 3. vSphere 8 Update 3 улучшает управление жизненным циклом, безопасность и производительность, включая поддержку двойных DPU и улучшенную настройку виртуального оборудования.

Многие администраторы часто добавляют новые хосты ESXi, но довольно редко обсуждается вопрос о том, как правильно выводить из эксплуатации хост VMware ESXi. Об этом интересную статью написал Stephen Wagner.

Многих может удивить, что нельзя просто выключить хост ESXi и удалить его из окружения сервера vCenter, так как необходимо выполнить ряд шагов заранее, чтобы обеспечить успешный вывод из эксплуатации (decomission). Правильное списание хоста ESXi предотвращает появление изолированных объектов в базе данных vCenter, которые иногда могут вызывать проблемы в будущем.

Итак, процесс: как списать хост ESXi

Предполагается, что вы уже перенесли все ваши виртуальные машины, шаблоны и файлы с хоста, и он не содержит данных, которые требуют резервного копирования или миграции. Если вы этого не сделали - проверьте все еще раз, на хосте могут оказаться, например, кастомные скрипты, которые вы не сохраняли в другом месте.

Вкратце процесс выглядит так:

• Перевод ESXi в режим обслуживания (Maintenance Mode)
• Удаление хоста из распределенного коммутатора vSphere Distributed Switch (vDS)
• Отключение и размонтирование томов iSCSI LUN
• Перемещение хоста из кластера в датацентр как отдельного хоста
• Удаление хоста из инвентаря (Inventory)
• Выполнение расширенных процедур

Вход в режим обслуживания

Мы переходим в режим обслуживания, чтобы убедиться, что на хосте не запущены виртуальные машины. Вы можете просто щелкнуть правой кнопкой мыши по хосту и войти в режим обслуживания (Enter Maintenance Mode):

Если хост ESXi входит в состав кластера VMware vSAN, то вам будут предложены опции того, что нужно сделать с данными на нем хранящимися:

Удаление хоста из окружения vSphere Distributed Switch (vDS)

Необходимо аккуратно удалить хост из любых распределенных коммутаторов vDS (VMware Distributed Switches) перед удалением хоста из сервера vCenter.

Вы можете создать стандартный vSwitch и мигрировать адаптеры vmk (VMware Kernel) с vDS на обычный vSwitch, чтобы поддерживать связь с сервером vCenter и другими сетями.

Обратите внимание, что если вы используете коммутаторы vDS для подключений iSCSI, необходимо заранее разработать план по этому поводу, либо размонтировать/отключить iSCSI LUN на vDS перед удалением хоста, либо аккуратно мигрировать адаптеры vmk на стандартный vSwitch, используя MPIO для предотвращения потери связи во время выполнения процесса.

Размонтирование и отключение iSCSI LUN

Теперь вы можете приступить к размонтированию и отключению iSCSI LUN с выбранного хоста ESXi:

• Размонтируйте тома iSCSI LUN с хоста
• Отключите эти iSCSI LUN

Нужно размонтировать LUN только на выводимом из эксплуатации хосте, а затем отключить LUN также только на списываемом хосте.

Перемещение хоста из кластера в датацентр как отдельного хоста

Хотя это может быть необязательным, это полезно, чтобы позволить службам кластера vSphere (HA/DRS) адаптироваться к удалению хоста, а также обработать реконфигурацию агента HA на хосте ESXi. Для этого вы можете просто переместить хост из кластера на уровень родительского дата-центра.

Удаление хоста из инвентаря

После перемещения хоста и прошествия некоторого времени, вы теперь можете приступить к его удалению из Inventory. Пока хост включен и все еще подключен к vCenter, щелкните правой кнопкой мыши по хосту и выберите «Remove from Inventory». Это позволит аккуратно удалить объекты из vCenter, а также удалить агент HA с хоста ESXi.

Повторное использование хоста

Начиная с этого момента, вы можете войти напрямую на хост ESXi с помощью локального пароля root и выключить хост. Сделать этого можно также с помощью обновленного VMware Host Client.

Многие администраторы помнят, что при анонсе платформы vSphere 8 в прошлом году компания VMware представила технологическое превью технологии Configuration Profiles, которая пришла на смену устаревшему механизму Host Profiles. В недавно состоявшемся релизе vSphere 8 Update 1 движок Configuration Profiles стал полностью поддерживаться в производственной среде. Теперь администраторы могут начать использование этой функциональности и смигрировать в эту среду...

На сайте проекта VMware Labs появилась очередная полезная для Enterprise-администраторов утилита - Cloud Foundation Configuration File Generator.

VMware Cloud Foundation позволяет развертывать гибкую инфраструктуру для исполнения различных типов приложений в компании. Процесс развертывания автоматизируется с помощью виртуального модуля VMware Cloud Builder, который требует ввода специфических данных от клиента, которые затем используются для описания конфигурации платформы.

На сегодняшний день эти данные собираются с помощью электронной таблицы Excel, называемой Deployment Parameter Workbook. После заполнения таблицы она загружается в VMware Cloud Builder, где система преобразует исходные данные в формат JSON, производит проверку корректности ввода данных и параметров физической инфраструктуры, а затем запускает процесс развертывания. Также возможно вручную создать JSON, чтобы настроить дополнительные варианты использования, которые не охватываются таблицей Excel.

Также проверка правильности ввода данных в Deployment Parameter Workbook ограничена из-за невозможности использования VBScript из-за проблем с безопасностью.

VMware Cloud Foundation Configuration File Generator является контейнеризованным веб-приложением, разработанным для замены электронной таблицы Deployment Parameter Workbook. Использование веб-приложения позволяет проводить проверку ввода данных на ранней стадии на всех этапах, что уменьшает ошибки ввода данных и исключает неприятные ошибки при проверке, когда таблица загружается в VMware Cloud Builder.

Основные преимущества использования утилиты:

• Полная валидация вводимых данных
• Портируемость спецификаций JSON для повторного использования или в качестве источника для создания новой конфигурации
• Возможность добавить более 4 хостов ESXi в management domain
• Возможность добавить несколько распределенных коммутаторов
• Возможность добавить несколько физических адаптеров pNIC для конфигурации vSphere Distributed switch
• Возможность настроить сети management networks (Management, vSAN, vMotion) между несколькими распределенными коммутаторами

Скачать VMware Cloud Foundation Configuration File Generator можно по этой ссылке.

На прошлой неделе мы рассказали о новых возможностях обновленной версии платформы VMware vSphere 8 Update 1, а также новых функциях инфраструктуры хранилищ (Core Storage). Сегодня мы поговорим о новой версии vSAN 8 Update 1 - решения для организации отказоустойчивых кластеров хранилищ для виртуальных машин.

В vSAN 8 компания VMware представила архитектуру хранилища vSAN Express Storage Architecture (ESA), сделав весомый вклад в развитие гиперконвергентной инфраструктуры. В первом пакете обновлений vSAN компания VMware продолжает развивать этот продукт, позволяя клиентам использовать современные массивы, которые обеспечивают новый уровень производительности, масштабируемости, надежности и простоты использования.

Обзор основных возможностей vSAN 8 Update 1 вы также можете увидеть в видео ниже (откроется в новом окне):

В vSAN 8 Update 1 продолжают разрабатывать и улучшать обе архитектуры - vSAN OSA и vSAN ESA. Давайте посмотрим, что нового появилось в vSAN U1:

1. Масштабирование распределенных хранилищ

Обработка разделенных ресурсов вычисления и хранения в кластерах улучшена в версии vSAN 8 U1. Клиенты могут масштабироваться новыми способами, совместно используя хранилища данных vSAN с другими кластерами vSAN или только с вычислительными кластерами vSphere в рамках подхода HCI Mesh.

• Управление распределенными хранилищами HCI Mesh с помощью архитектуры Express Storage

В vSAN 8 U1 архитектура Express Storage Architecture (ESA) позволяет клиентам максимизировать использование ресурсов устройств нового поколения путем предоставления общего доступа к хранилищами в нескольких нерастянутых кластерах для подхода HCI Mesh. Пользователи могут монтировать удаленные хранилища данных vSAN, расположенные в других кластерах vSAN, и использовать кластер vSAN ESA в качестве внешнего хранилища ресурсов для кластера vSphere.

• Использование внешнего хранилища с помощью растянутых кластеров vSAN для OSA

В vSAN 8 U1 появилась поддержка распределенных хранилищ HCI Mesh при использовании растянутых кластеров vSAN на основе архитектуры хранения vSAN OSA. Теперь пользователи могут масштабировать хранение и вычислительные мощности независимо - в стандартных и растянутых кластерах.

• Потребление емкостей хранилищ vSAN для разных экземпляров vCenter Server

vSAN 8 U1 также поддерживает распределенные хранилища в разных средах с использованием нескольких серверов vCenter при использовании традиционной архитектуры хранения (OSA).

2. Улучшение платформы

• Улучшенная производительность с использованием нового адаптивного пути записи

В новом релизе представлен новый адаптивный путь записи, который позволяет рабочим нагрузкам с множеством записей и частопоследовательными записями записывать данные оптимальным способом. Улучшенная потоковая запись на ESA обеспечит увеличение пропускной способности на 25% и снижение задержки для последовательных записей. Это обновление не только повлияет на приложения с преобладающим профилем последовательной записи I/O, но и расширит разнообразие нагрузок, которые работают оптимальным образом на ESA vSAN.

• Улучшенная производительность для отдельных нагрузок

Чтобы извлечь максимальную пользу из современного оборудования NVMe, в vSAN ESA 8 U1 была оптимизирована обработка I/O для каждого объекта, находящегося на хранилище данных vSAN ESA, повысив производительность на каждый VMDK на 25%. Эти улучшения производительности для отдельных объектов на ESA будут очень эффективны на критически важных виртуальных машинах, включая приложения, такие как реляционные базы данных и нагрузки OLTP.

• Улучшенная надежность во время сценариев режима обслуживания.

В vSAN 8 U1 для ESA была добавлена еще одна функция, которая присутствует в vSAN OSA: поддержка RAID 5 и RAID 6 erasure coding с функциями дополнительной защиты от потери данных во время плановых операций обслуживания. Эта новая возможность гарантирует, что данные на ESA хранятся с избыточностью в случае неожиданного сбоя хоста в кластере во время режима обслуживания.

• Улучшения управления датасторами

В vSAN 8 U1 администраторы смогут настраивать размер объектов пространства имен, что позволит им более просто хранить файлы ISO и библиотеки контента.

3. Упрощение управления

При использовании управления хранилищем на основе политик (SPBM), клиенты могут определять возможности хранения с помощью политик и применять их на уровне виртуальных машин. vSAN 8 U1 есть несколько новых улучшений, которые упрощают ежедневные операции администраторов, а также добавляют несколько новых возможностей, чтобы помочь глобальной команде поддержки VMware (GS) быстрее решать проблемы клиентов.

• Автоматическое управление политиками для Default Storage Policies (ESA)

В vSAN ESA 8 U1 появилась новая, необязательная кластерная политика хранения по умолчанию, которая поможет администраторам работать с кластерами ESA с оптимальной надежностью и эффективностью. В конфигурации на уровне кластера доступен новый переключатель "Auto-Policy Management". При включении этой функции кластера будет создана и назначена эффективная политика хранения по умолчанию на основе размера и типа кластера.

• Skyline Health Score и исправление конфигурации

В vSAN 8 U1 модуль Skyline UX был переработан и теперь содержит новую панель управления состоянием с упрощенным видом "здоровья" каждого кластера. Новый пользовательский интерфейс поможет ответить на вопросы: "Находится ли мой кластер и обрабатываемые им нагрузки в работоспособном и здоровом состоянии?" и "Насколько серьезно это состояние? Следует ли решить эту проблему?".

С таким четким пониманием потенциальных проблем и действий для их устранения вы можете сократить среднее время до устранения проблем (mean time to resolution, MTTR).

• Более высокий уровень детализации для улучшенного анализа производительности

Доступный как в Express Storage Architecture, так и в Original Storage Architecture, сервис производительности vSAN 8 U1 теперь включает мониторинг производительности почти в реальном времени, который собирает и отображает показатели производительности каждые 30 секунд.

• Упрощенный сбор диагностической информации о производительности

В vSAN 8 U1 в I/O Trip Analyzer для виртуальных машин появился новый механизм планировщика. Вы можете запускать диагностику программно, что позволяет собирать больше и лучших данных, что может быть критически важно для выявления временных проблем производительности. Это улучшение идеально подходит для сред, где ВМ имеет повторяющуюся (хоть и кратковременную) проблему с производительностью.

• Новая интеграция PowerCLI

В vSAN 8 U1 PowerCLI поддерживает множество новых возможностей как для архитектур ESA (Express Storage Architecture), так и OSA (Original Storage Architecture). С помощью этих интеграций клиенты ESA получат простой доступ к своему инвентарю для мониторинга и автоматизации управления своей средой и выделением ресурсов.

4. Функции Cloud Native Storage

Выделенные окружения DevOps увеличивают сложность всего центра обработки данных и увеличивают затраты. Используя существующую среду vSphere для хостинга рабочих нагрузок Kubernetes DevOps, клиенты дополнительно увеличивают ценность и ROI платформы VMware. VMware продолжает фокусироваться на потребностях разработчиков: в vSAN 8 U1 были реализованы новые улучшения производительности, простоты и гибкости для разработчиков, которые используют среду, и для администраторов, ответственных за саму платформу.

• Поддержка CNS для vSAN ESA

В vSAN 8 U1 мы добавили поддержку Cloud Native Storage (CNS) для vSAN ESA. Клиенты могут получить преимущества производительности vSAN ESA для своих сред DevOps.

• Поддержка DPp общих виртуальных коммутаторов

vSAN 8 U1 снижает стоимость и сложность инфраструктуры за счет того, что решения DPp (Data Persistence) теперь совместимы с VMware vSphere Distributed Switch. Клиентам нужны только лицензии vSphere+/vSAN+, чтобы использовать платформу Data Persistence — на vSAN OSA или ESA — и запускать приложения, что дает более низкую общую стоимость владения и упрощение операций.

• Развертывние Thick provisioning для vSAN Direct Configuration

Наконец, в vSAN 8 U1 были доработаны кластеры, работающие в конфигурации vSAN Direct Configuration — это уникальная кластерная конфигурация, настроенная под Cloud Native Workloads. С vSAN 8 U1 постоянные тома могут быть программно выделены разработчиком как "thick" (это определяется в классе хранения).

Более подробно о новых возможностях VMware vSAN 8 Update 1 можно почитать на специальной странице.

В марте компания VMware анонсировала скорую доступность первого пакета обновлений своей флагманской платформы виртуализации VMware vSphere 8.0 Update 1. Напомним, что прошлая версия VMware vSphere 8.0 была анонсирована на конференции VMware Explore 2022 в августе прошлого года.

Давайте посмотрим, что нового появилось в vSphere 8.0 U1:

1. Полная поддержка vSphere Configuration Profiles

В vSphere 8.0 эта функциональность впервые появилась и работала в режиме технологического превью, а в Update 1 она полностью вышла в продакшен. Эта возможность представляет собой новое поколение инструментов для управления конфигурациями кластеров и заменяет предыдущую функцию Host Profiles. Ее особенности:

• Установка желаемой конфигурации на уровне кластера в форме JSON-документа
• Проверка хостов на соответствие желаемой конфигурации
• При выявлении несоответствий - перенастройка хостов на заданный уровень конфигурации

В vSphere 8 Update 1 возможности Configuration Profiles поддерживают настройку распределенных коммутаторов vSphere Distributed Switch, которая не была доступна в режиме технологического превью. Однако, окружения, использующие VMware NSX, все еще не поддерживаются.

Существующие кластеры можно перевести под управление Configuration Profiles. Если для кластера есть привязанный профиль Host Profile, то вы увидите предупреждение об удалении профиля, когда кластер будет переведен в Configuration Profiles. Как только переход будет закончен, Host Profiles уже нельзя будет привязать к кластеру и хостам.

Если кластер все еще использует управление жизненным циклом на базе бейзлайнов, то сначала кластер нужно перевести в режим управления image-based:

vSphere Configuration Profiles могут быть активированы при создании нового кластера. Это требует, чтобы кластер управлялся на основе единого определения образа. После создания кластера доступна кастомизация конфигурации. Более подробно о возможностях Configuration Profiles можно почитать здесь.

2. vSphere Lifecycle Manager для отдельных хостов

В vSphere 8 появилась возможность управлять через vSphere Lifecycle Manager отдельными хостами ESXi под управлением vCenter посредством vSphere API. В Update 1 теперь есть полная поддержка vSphere Client для этого процесса - создать образ, проверить и привести в соответствие, а также другие функции.

Все, что вы ожидаете от vSphere Lifecycle Manager для взаимодействия с кластером vSphere, вы можете делать и для отдельных хостов, включая стейджинг и функции ESXi Quick Boot.

Также вы можете определить кастомные image depots для отдельных хостов - это полезно, когда у вас есть хост, который находится на уровне edge и должен использовать depot, размещенный совместно с хостом ESXi, во избежание проблем с настройкой конфигурации при плохом соединении удаленных друг от друга хостов ESXi и vCenter.

3. Различные GPU-нагрузки хоста на базе одной видеокарты

В предыдущих версиях vSphere все рабочие нагрузки NVIDIA vGPU должны были использовать тот же самый тип профиля vGPU и размер памяти vGPU. В vSphere 8 U1 модули NVIDIA vGPU могут быть назначены для различных типов профилей. Однако, размер памяти для них должен быть, по-прежнему, одинаковым. Например, на картинке ниже мы видим 3 виртуальных машины, каждая с разным профилем (B,C и Q) и размером памяти 8 ГБ. Это позволяет более эффективно разделять ресурсы между нагрузками разных видов.

NVIDIA позволяет создавать следующие типы профилей vGPU:

• Profile type A - для потоково доставляемых приложений или для решений на базе сессий
• Profile type B - для VDI-приложений
• Profile type C - для приложений, требовательных к вычислительным ресурсам (например, machine learning)
• Profile type Q - для приложений, требовательных к графике

4. Службы Supervisor Services для vSphere Distributed Switch

В vSphere 8 Update 1, в дополнение к VM Service, службы Supervisor Services теперь доступны при использовании сетевого стека vSphere Distributed Switch.

Supervisor Services - это сертифицированные в vSphere операторы Kubernetes, которые реализуют компоненты Infrastructure-as-a-Service, тесно интегрированные со службами независимых разработчиков ПО. Вы можете установить и управлять Supervisor Services в окружении vSphere with Tanzu, чтобы сделать их доступными для использования рабочими нагрузками Kubernetes. Когда Supervisor Services установлены на Supervisors, инженеры DevOps могут использовать API для создания инстансов на Supervisors в рамках пользовательских пространств имен.

Более подробно об этом рассказано тут.

5. Функция Bring Your Own Image для VM Service

Возможность VM Service была доработана, чтобы поддерживать образы ВМ, созданные пользователями. Теперь администраторы могут собирать собственные пайплайны сборки образов с поддержкой CloudInit и vAppConfig.

Администраторы могут добавить эти новые шаблоны ВМ в Content library, чтобы они стали доступны команде DevOps. А сами DevOps создают спецификацию cloud-config, которая настроит ВМ при первой загрузке. Команда DevOps отправляет спецификацию ВМ вместе cloud-config для создания и настройки ВМ.

Более подробно об этом можно почитать тут и тут.

6. Консоли виртуальных машин для DevOps

DevOps могут теперь получать простой доступ к виртуальным машинам, которые они развернули, с использованием kubectl.

В этом случае создается уникальная ссылка, по которой можно получить доступ к консоли ВМ, и которая не требует настройки разрешений через vSphere Client. Веб-консоль дает по этому URL доступ пользователю к консоли машины в течение двух минут. В этом случае нужен доступ к Supervisor Control Plane по порту 443.

Веб-консоль ВМ дает возможности самостоятельной отладки и траблшутинга даже для тех ВМ, у которых может не быть доступа к сети и настроенного SSH.

7. Интегрированный плагин Skyline Health Diagnostics

Теперь развертывание и управление VMware Skyline Health Diagnostics упростилось за счет рабочего процесса, встроенного в vSphere Client, который дает возможность просто развернуть виртуальный модуль и зарегистрировать его в vCenter.

Skyline Health Diagnostics позволяет вам:

• Диагностировать и исправлять различные типы отказов в инфраструктуре
• Выполнять проверку состояния компонентов (health checks)
• Понимать применимость VMware Security Advisories и связанных элементов
• Обнаруживать проблемы, которые влияют на апдейты и апгрейды продукта

Утилита использует логи, конфигурационную информацию и другие источники для обнаружения проблем и предоставления рекомендаций в форме ссылок на статьи KB или шагов по исправлению ситуации.

8. Улучшенные метрики vSphere Green Metrics

В vSphere 8.0 появились метрики, которые отображают потребление энергии виртуальными машинами с точки зрения энергоэффективности виртуального датацентра. В vSphere 8.0 Update 1 теперь можно отслеживать их на уровне отдельных ВМ. Они берут во внимание объем ресурсов ВМ, чтобы дать пользователю более точную информацию об энергоэффективности на уровне отдельных нагрузок. Разработчики также могут получать их через API, а владельцы приложений могут получать агрегированное представление этих данных.

Метрика Static Power - это смоделированное потребление мощности простаивающих ресурсов ВМ, как если бы она был хостом bare-metal с такими же аппаратными параметрами процессора и памяти. Static Power оценивает затраты на поддержание таких хостов во включенном состоянии. Ну а Usage - это реально измеренное потребление мощности ВМ в активном режиме использования CPU и памяти, которые запрашиваются через интерфейс (IPMI - Intelligent Platform Management Interface).

9. Функция Okta Identity Federation для vCenter

vSphere 8 Update 1 поддерживает управление идентификациями и многофакторной аутентификацией в облаке, для чего на старте реализована поддержка Okta.

Использование Federated identity подразумевает, что vSphere не видит пользовательских учетных данных, что увеличивает безопасность. Это работает по аналогии со сторонними движками аутентификации в вебе, к которым пользователи уже привыкли (например, логин через Google).

10. Функции ESXi Quick Boot для защищенных систем

vSphere начала поддерживать Quick Boot еще с версии vSphere 6.7. Теперь хосты с поддержкой TPM 2.0 проходят через безопасный процесс загрузки и аттестации, что позволяет убедиться в неизменности хоста - а это надежный способ предотвратить атаки malware. Quick Boot теперь стал полноценно совместимым процессом в vSphere 8 Update 1.

11. Поддержка vSphere Fault Tolerance с устройствами vTPM

Функции непрерывной доступности VMware vSphere Fault Tolerance (FT) позволяют подхватить исполнение рабочей нагрузки на резервном хосте без простоя в случае проблем основной ВМ. Теперь эта функция поддерживает ВМ, настроенные с устройствами vTPM.

Модели Virtual TPM - это важный компонент инфраструктуры, используемый такими решениями, как Microsoft Device Guard, Credential Guard, Virtualization-Based Security, Secure Boot & OS attestation, а также многими другими. Это, зачастую, и часть регуляторных требований комплаенса.

12. Поддержка Nvidia NVSwitch

В рамках партнерства с NVIDIA, VMware продолжает расширять поддержку продуктового портфеля этого вендора.

Эта технология используется в high-performance computing (HPC) и для AI-приложений (deep learning, научное моделирование и анализ больших данных), что требует работы модулей GPU совместно в параллельном режиме. В современном серверном оборудовании различные приложения ограничены параметрами шины. Чтобы решить эту проблему, NVIDIA создала специальный коммутатор NVSwitch, который позволяет до 8 GPU взаимодействовать на максимальной скорости.

Вот нюансы технологий NVLink и NVSwitch:

• NVLink - это бэкенд протокол для коммутаторов NVSwitch. NVLink создает мост для соединений точка-точка и может быть использован для линковки от 2 до 4 GPU на очень высокой скорости.
• NVSwitch требует, чтобы более 4 GPU были соединены, а также использует поддержку vSphere 8U1 NVSwitch для формирования разделов из 2, 4 и 8 GPU для работы виртуальных машин.
• NVLink использует архитектуру Hopper, что предполагает создания пары GPU, которые передают до 450 GB/s (то есть общая скорость до 900 GB/s).

Для сравнения архитектура Gen5 x16 может передавать на скорости до 64 GB/s, то есть NVLink и NVSwitch дают очень существенный прирост в скорости.

13. Функции VM DirectPath I/O Hot-Plug для NVMe

В прошлых релизах добавление или удаление устройств VM DirectPath IO требовало нахождения ВМ в выключенном состоянии. Теперь же в vSphere 8 Update 1 появилась поддержка горячего добавления и удаления устройств NVMe через vSphere API.

На этом пока все, в следующих статьях мы расскажем об улучшениях Core Storage в vSphere 8 Update 1.

Наш постоянный читатель Сергей обратил внимание на то, что недавно вышла новая версия средства мониторинга ИТ-инфраструктуры Zabbix 6.2, в которой есть много всего нового и полезного для наблюдения за виртуальной инфраструктурой VMware vSphere.

Давайте посмотрим, что там интересного в плане работы с хостами vSphere:

• Возможность вручную назначать шаблоны обнаруженным хостам ESXi
• Создание и изменение пользовательских макросов для обнаруженных хостов ESXi
• Добавление дополнительных тэгов для серверов

Также функции мониторинга были доработаны, чтобы поддерживать новые сущности и низкоуровневые правила их обнаружения.

Это позволяет отслеживать новые метрики, а именно:

• Статус алармов серверов
• Число снапшотов и время их создания
• Метрики сетевых интерфейсов ESXi
• Метрики портов распределенного коммутатора vSphere Distributed Switch
• Метрики IOPS read/write для датасторов
• Другие счетчики производительности датасторов
• Состояние гостевых ОС

• Прочие метрики из разных категорий

Также теперь обнаружение хостов VMware vSphere может быть отфильтровано на базе их статуса включенности (например, можно добавить только работающие сейчас хосты ESXi).

Более подробно о новой версии Zabbix 6.2 можно почитать на этой странице. Скачать продукт можно тут.

В конце января компания VMware объявила об очередном обновлении своей флагманской облачной платформы VMware Cloud on AWS January 2023 (сокращенно она называется VMConAWS). Напомним, что она построена на архитектуре VMware vSphere, которая работает поверх инфраструктуры Amazon AWS. В последний раз мы писали об обновлении этой платформы летом прошлого года.

Давайте посмотрим, что нового теперь есть в VMware Cloud on AWS:

1. Улучшения поддержки enterprise-нагрузок

• Расширение доступности AWS в Африке (локация Кейптаун). Теперь в состав сервиса входит 22 региона. Подробнее об этом тут.
• Модернизация приложений в рамках VMware Cloud on AWS - здесь появилась возможность миграции приложений с минимальным простоем за счет использования Kubernetes, нативных облачных сервисов и средства автоматизации инфраструктуры. Также появилась группировка SDDC средствами Terraform - этот функционал позволяет сгруппировать объекты как код в рамках рабочих процессов автоматизации. Подробнее тут.

2. Улучшения в работе с ресурсами облака

• Теперь инстанс Amazon EC2 i4i.metal доступен для всех клиентов облака. Теперь можно выбрать i4i.metal как при развертывании нового SDDC, так и смигрировать рабочие нагрузки с хостов i3.metal и i3en.metal. Напомним, что новый инстанс i4 построен на базе процессоров Intel Xeon Ice Lake третьего поколения, которые дают лучшую производительность ввода-вывода и повышенную безопасность. Подробнее об этом тут.

Если вкратце, то вот характеристики производительности i4i.metal (на базе результатов SQL Server benchmarking tool):

• ~20TiB хранилища NVMe (в 2 раза больше, чем у i3.metal) 
• 64 физических / 128 логических CPU (в 1.8 раза больше)  
• 1 024 ГБ памяти (в 2 раза больше) 
• Скорость соединения до 75 Gbps (в 3 раза выше) 
• Включенное по умолчанию шифрование host encryption
• Улучшенная производительность по сравнению с i3.metal на 125% в целом и на 51% выше, чем у i3en.metal

Также появились автоматически обновления firmware для существующих развертываний SDDC. На время обновления появляется новый бесплатный хост в инфраструктуре, который поддерживает нужный уровень емкостей датацентра. Подробнее тут.

Кроме того, появилось несколько улучшений в плане хранилищ:

• Поддержка одной зоны доступности AZ для интеграции между Amazon FSx for NetApp ONTAP. Подробнее тут.
• Финальная доступность VMware Cloud Flex Storage - мы писали об этом здесь. В решении доступны такие возможности, как эффективные снапшоты, неизменяемость бэкапов (immutability), защита от ransomware и многое другое, что позволяет использовать их для разных типов организаций и рабочих нагрузок.

3. Улучшения механизмов доступности и надежности

• VMware Cloud Disaster Recovery - теперь появилось расширение географической доступности на AWS Africa (Cape Town).
• VMware Site Recovery - появилась поддержка инстансов I4i.metal, а также был добавлен регион AWS Africa (Cape Town).

4. Изменения в сайзинге, ценообразовании и подписках

• Окончание продаж подписок на 1 и 3 года для инстансов i3.metal в связи с выпуском I4i.metal. Более подробно об этом тут.
• Включение VMware Cloud Flex Storage в программу VMware Cloud Universal.
• Мультиоблачная программа по адаптации пользователей - Multi-Cloud Adoption Program (MCAP). Она была анонсирована в прошлом году, а сейчас запущена и расширена на большую партнерскую экосистему.

5. Улучшения пользовательского опыта

В связи с выпуском решения VMware Ransomware Recovery as a Service, оно было включено в решение VMware Cloud Launchpad. Эта программа позволяет пользователям понять, как выходить из ситуации, когда инфраструктуру атаковало Ransomware.

6. Улучшения решения VMware HCX

• Поддержка прямой миграции vMotion для переноса с NSX-V на NSX-T в рамках процесса HCX Assisted vMotion.
• Поддержка OSAM (OS Assisted Migration) для RHEL 8.5 и 8.6.
• Поддержка кастомных атрибутов Power CLI.
• Поддержка технологии Mobility Optimized Networking (MON) для нескольких IP и адаптеров vNIC.
• Поддержка Replication Assisted vMotion (RAV) Seed Checkpoint для больших миграций (создается контрольная точка, с которой можно продолжить неудачно завершившуюся миграцию).
• Поддержка последних версий vSphere 8.0, VM Hardware version 20, vSAN 8 и vSphere Distributed switch version 8.
• Платформа VMware HCX 4.5 теперь поддерживается для пользователей, работающих в среде VMware Cloud on AWS SDDC Version 1.20+.
• Пользователи могут видеть детали deployment / un-deployment при просмотре статуса задачи.
• Простая фильтрация событий миграции на дэшборде, что удобно при большом количестве миграций.
• Добавлен диагностический тест для проверки доступности порта управления, также есть сбор статистики по каналу передачи.
• Улучшен механизм очистки устаревших данных при обработке неудачных или отмененных миграций.
• Возможность просмотра задач, которые завершились успешно, но с предупреждениями.

Больше подробностей о новой версии VMware HCX 4.5 можно узнать по этой ссылке. Ну а главная страница платформы VMware Cloud on AWS находится здесь (а тут - последние Release Notes).

В рамках событий первого дня проходящей сейчас конференции VMware Explore 2022 была анонсировала платформа виртуализации VMware vSphere 8. Это событие очень ждали многие администраторы и менеджеры датацентров, так как с момента релиза прошлой мажорной версии платформы VMware vSphere 7 прошло уже два с половиной года. Давайте посмотрим, что нового в VMware vSphere 8...

Довольно давно мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).

Также некоторое время назад мы писали о VMware Paravirtual RDMA (PVRDMA) - технологии, поддержка которой появилась еще в VMware vSphere 6.5. С помощью нее для сетевых адаптеров PCIe с поддержкой RDMA можно обмениваться данными памяти для виртуальных машин напрямую через RDMA API, что важно для нагрузок High Performance Computing (HPC) на платформе vSphere.

Работает PVRDMA только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Альтернативой этому режиму использования сетевых карт является технология VMDirectPath I/O (passthrough), которая напрямую пробрасывает устройство в виртуальную машину. Это, конечно, самый оптимальный путь с точки зрения производительности, однако он не позволяет использовать многие полезные технологии VMware, такие как HA, DRS и vMotion.

Недавно компания VMware выпустила интересный документ "Paravirtual RDMA for High Performance Computing", где рассматриваются аспекты развертывания и производительности PVRDMA, а также производится тестирование этой технологии в сравнении с VMDirectPath I/O и TCP/IP:

Читать весь документ, наверное, не стоит - можно довериться методике тестирования VMware и ее подходу к оценке производительности. Тестовый стенд выглядел так:

Состав оборудования и особенности тестирования:

• 8 хостов ESXi 7.0 на платформе PowerEdge C6420 с Intel Xeon Gold 6148 CPU на борту (20 ядер / 40 потоков), 200GB RAM NVIDIA Mellanox ConnectX-5 Ex 100GbE NIC на канале RDMA
• Карты NVIDIA Mellanox ConnectX-5 Ex NIC, соединенные через коммутатор 100GbE NVIDIA Mellanox
• CentOS 7.6, 20 vCPUs, 100GB RAM, ВМ на датасторе vSAN, одна ВМ на хост ESXi
• OpenMPI версии 4.1.0, использующая using openib BTL для транспорта RDMA
• OpenFOAM версии 8, исполняющая тест cavityFine из руководства OpenFOAM. Этот тест исполняет симуляцию течения жидкости с заданными параметрами.

Тут можно просто взглянуть на следующие картинки, чтобы понять, что при использовании PVRDMA вы теряете не так уж и много в сравнении с VMDirectPath I/O.

Результаты теста по времени исполнения в секундах (для 2,4 и 8 хостов, соответственно):

Визуализация результатов при изменении числа узлов:

В среднем, потери производительности на PVRDMA составляют до 20%, зато вы получаете множество преимуществ, которые дает полная виртуализация без жесткой привязки к оборудованию - консолидация, HA и vMotion:

В сравнении с TCP дела тоже обстоят хорошо, результат лучше на 30-80%, в зависимости от числа узлов:

Скачать документ VMware Paravirtual RDMA for High Performance Computing можно по этой ссылке.

Как знают многие администраторы VMware vSphere, у компании есть очень полезный документ "Security Configuration Guide", который представляет собой основное руководство по обеспечению безопасности виртуальной среды. Последняя версия этого документа содержит 87 настроек (мы писали об этом тут), так или иначе влияющих на безопасность как самой платформы виртуализации, так и виртуальных машин и их гостевых операционных систем.

Документ передает концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований именно в вашей инфраструктуре.

Надо понимать, что конфигурация виртуальной среды в целях обеспечения повышенной (относительно дефолтной) безопасности - это всегда компромисс между защищенностью и удобством использования (как и для любой другой ИТ-системы). Из коробки сама платформа, сервер vCenter и виртуальные машины настроены таким образом, чтобы обеспечить максимальное удобство использования при должном уровне безопасности.

Помните, что изменение настроек безопасности - очень опасная штука, которая требует обязательного документирования и оповещения администраторов об этом. Ведь из-за этого они могут получить проблемы с работой отдельных компонентов, но так и не понять их источника, что будет похуже чисто гипотетической маловероятной атаки, связанной с измененной настройкой.

Сегодня мы посмотрим на 15 действительно полезных рекомендаций и настроек, применение которых не сильно снизит удобство использования, но при этом даст чуть более высокий уровень безопасности, что может оказаться вам в каком-то случае полезным.

Структура списка конфигураций и рекомендаций

Давайте сначала взглянем на колонки Excel-таблицы, которая, по-сути, и является списком настроек и рекомендаций, которые вы можете применить в своей виртуальной инфраструктуре:

• Guideline ID - идентификационное имя рекомендации.
• Description - лаконичная формулировка сути этой рекомендации.
• Discussion - описание влияния настройки на конфигурацию среды и операции, а также обсуждение моментов, которые касаются удобства использования инструментов управления в связи с изменением настройки.
• Configuration Parameter - это название расширенной настройки соответствующего компонента, которую вы можете изменить. Понятно дело, что эта колонка заполнена не всегда, так как есть рекомендации, которые регулируются не конкретными настройками, а, например, топологией или подходом к организации среды.
• Desired value - рекомендуемое значение, часто оно является значением по умолчанию, если это не site specific.
• Default value - то значение, которое установлено по умолчанию.
• Is Desired Value the Default? - просто для понимания (и для референса в будущем), установлено ли желаемое значение по умолчанию.
• Action Needed - это тип действия, который необходимо предпринять - изменить настройку, проверить конфигурацию или топологию, добавить или удалить что-то и т.п.
• Setting Location in vSphere Client - очень полезная колонка, позволяющая вам найти нужную настройку в клиенте vSphere.
• Negative Functional Impact in Change From Default? - это как раз информация о влиянии на функционал в случае изменения настройки.
• PowerCLI Command Assessment - команда PowerCLI, с помощью которой можно узнать текущее значение настройки.
• PowerCLI Command Remediation Example - команда PowerCLI по применению настройки.
• Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
• Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
• Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено необоснованно.

Само руководство разбито на 4 категории, которые понятны всем администраторам:

• Хосты ESXi
• Сервер vCenter
• Виртуальные машины
• Гостевые ОС виртуальных машин

Также в документе есть и вкладка "Deprecated" - там находятся те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).

Итак, давайте посмотрим на 15 самых интересных и, главное, полезных настроек, которые вы можете изменить, а также рекомендаций, которые вы можете выполнять, чтобы повысить безопасность виртуальной среды в своей инфраструктуре.

Хосты ESXi

• Configure remote logging - это действительно правильная рекомендация. Хосты ESXi должны отправлять свои логи на удаленный сервер Syslog. Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware vRealize Log Insight. Ведь если злоумышленник проникнет на сервер ESXi, то после своей активности он эти логи удалит, и расследовать будет нечего. С централизованного внешнего сервера удалить эти данные сложнее. На работу виртуальной среды эта конфигурация не влияет.
• Ensure ESXi management interfaces are isolated on their own network segment - это очевидная, но не всегда выполняемая администраторами конфигурация. Конечно же, вся управляющая инфраструктура виртуальной среды должна находиться в выделенном сегменте сети в своих VLAN, куда имеют доступ только администраторы. То же самое касается и сети vMotion, и сети vSAN.
• esxi-7.shell-interactive-timeout и esxi-7.shell-timeout (Set a timeout to automatically terminate idle ESXi Shell and SSH sessions) - по умолчанию сессии командной оболочки и SSH-сессии висят постоянно, что, конечно же, представляет потенциальную угрозу. Лучше ограничить таймаут 600 секундами, чтобы никто эти сессии не смог подхватить.
• Only run binaries delivered via VIB - эта настройка позволяет устанавливать бинарные компоненты только через VIB-пакеты, которые соответствуют установленному Acceptance Level. Если вы не пользуетесь посторонними библиотеками кустарного производства, то лучше эту настройку включить. Когда вам понадобится установить такой бинарник - просто включите эту настройку снова. Но это изменение лучше задокументировать.
• Enable bidirectional/mutual CHAP authentication for iSCSI traffic - настраивать CHAP-аутентификацию нужно обязательно, чтобы предотвратить атаки, связанные с перехватом трафика к хранилищам. Настраивать это недолго, но зато будет больше уверенности в сохранности данных.

Сервер vCenter

• Ensure vCenter Server management interfaces are isolated on their own network segment or as part of an isolated ESXi management network - это та же самая рекомендация по изоляции управляющей сети от сети виртуальных машин, что и для серверов ESXi. Убедитесь, что они надежно разделены с помощью VLAN и других техник.
• Ensure that port mirroring is being used legitimately - эта настройка отключена по умолчанию, но зеркалирование трафика на портах vSphere Distributed Switch надо периодически проверять (vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> Port Mirroring). Такой способ атаки - один из самых простых в реализации, если у злоумышленника есть доступ к настройкам VDS (обычно в них никто не заглядывает после первичной настройки). То же самое касается и отправки трафика NetFlow, управление которым производится в разделе vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> NetFlow.
• Limit access to vCenter Server by restricting DCLI / SSH - это разумная рекомендация, чтобы злоумышленник не смог залогиниться в консоль виртуального модуля напрямую или по SSH. Уменьшив поверхность атаки, вы сделаете среду более защищенной. Только не забудьте задокументировать это изменение.
• Configure File-Based Backup and Recovery - не ленитесь настраивать и обслуживать бэкап конфигурации вашего управляющего сервера. Однажды это может вам пригодиться как в контексте безопасности, так и в контексте быстрого восстановления системы управления в виртуальной инфраструктуре в случае сбоя.
• Configure remote logging - здесь те же рекомендации, что и для ESXi. Не ленитесь настраивать сервер удаленного сбора логов.

Виртуальные машины

• Limit the number of console connections - очень часто к консоли виртуальной машины не нужно больше одного подключения ее администратора. В этом случае дефолтное количество 40 одновременных подключений лучше уменьшить до 1. Делается это в разделе VM -> Edit Settings -> VM Options -> VMware Remote Console Options.
• Encrypt VMs during vMotion - это полезная настройка. По умолчанию, трафик vMotion шифруется, только если есть такая возможность (Opportunistic). Если у вас хватает вычислительных ресурсов и быстрая сеть, то можно установить это значение в "Required". Это обеспечит защиту от перехвата трафика vMotion, в котором есть данные гостевой ОС виртуальной машины.
• Lock the VM guest session when the remote console is disconnected - лучше включить эту настройку и лочить сессию при отключении удаленной консоли, чтобы брошенная администратором сессия в гостевой ОС виртуальной машины не была подхвачена злоумышленником. На удобство работы это не сильно влияет. Изменить эту настройку можно в VM -> Edit Settings -> VM Options -> VMware Remote Console Options.

Гостевая ОС

• Ensure that VMware Tools are updated - это просто еще одно напоминание, что нужно постоянно следить за тем, что пакет VMware Tools обновлен до последней версии (и желательно поддерживать единый уровень версий для всех машин). В нем содержится много компонентов (кстати, не устанавливайте ненужные), поэтому уязвимость в одном из них может скомпрометировать множество виртуальных машин. То же самое относится и к версии Virtual Hardware - следите за этим.
• Disable Appinfo information gathering - об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы и их параметрах. Механизм Appinfo используется различными решениями, такими как vRealize Operations Manager, для мониторинга на уровне гостевой ОС. Если же вы не используете эти решения в своей виртуальной среде, то данный механизм лучше просто отключить через VMware Tools. Учитывая какое количество багов, касающихся безопасности, в последнее время находится в различных компонентах инфраструктурного ПО, лучше отключить функции Appinfo, которые включены по умолчанию для всех гостевых ОС после установки VMware Tools.

Конечно же, в документе vSphere 7 Security Configuration Guide есть много и других настроек и конфигураций, изменение которых помогут вам повысить уровень безопасности. Иногда это связано с требованиями регулирующих органов или спецификой внутренних политик организации. Поэтому обратите особенное внимание на те конфигурации, которые помечены как Site Specific, а также те, где рекомендуемые значения отличаются от дефолтных. И обязательно документируйте сделанные изменения, а также проводите регулярный аудит наиболее важных настроек.

На днях компания VMware объявила о скором обновлении своего средства NSX-T до версии 3.2. Напомним, что NSX-T - это решение для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров, физических серверов и контейнеров приложений Kubernetes. О версии VMware NSX-T 3.0 мы писали в прошлом году вот тут.

Отметим, что поддержка продукта VMware NSX Data Center for vSphere заканчивается 16 января 2022 года, поэтому все партнеры и клиенты должны перевести рабочие нагрузки на VMware NSX-T. При этом могут переезжать как окружения на базе Cloud Director, так и без него - все ресурсы, описывающие этот процесс, доступны. Основной инструмент для этого переезда - это VMware NSX Data Center for vSphere to VMware NSX-T Data Center migration tool.

Давайте посмотрим, что появилось нового в VMware NSX-T 3.2.

Функции мультиоблачной безопасности

Здесь появились следующие улучшения:

1. Возможности Tapless Network Traffic Analysis (NTA)

Функции Network traffic analysis (NTA) и средства для создания песочниц интегрированы в единый NSX Distributed Firewall (DFW). Сам сервис NTA встроен в гипервизор. Вместе с функциями IDS/IPS решения NSX администраторы могут виртуализовать весь стек безопасности и устранить слепые зоны для применения политик безопасности, чтобы контролировать сетевые потоки, безотносительно того, какие физические уровни под ними лежат.

2. Сетевой экран шлюза (Gateway Firewall)

Улучшенный gateway firewall служит как программный шлюз с возможностью контроля на уровнях L2-L7, включая URL-фильтрацию и расширенные функции предотвращения угроз с возможностями анализа вредоносного ПО и сэндбоксинга.

Это расширяет функции централизованного управления безопасностью на физические нагрузки, периметр датацентра и оконечные устройства, что дает возможность реализовать концепцию east-west и north-south по защите данных под центральным управлением движка NSX Intelligence.

3. Интегрированный механизм NDR и NSX Intelligence

Теперь решение NSX Network Detection and Response (NDR) интегрировано в платформу NSX Intelligence, что позволяет решению NDR понимать сигналы от IDS/IPS, NTA и сэндбокса, чтобы идентифицировать настоящие вторжения. Также NSX Intelligence получил улучшения производительности, а также улучшения движка рекомендаций для правил фаервола.

4. Распределенная Switch-agnostic безопасность

NSX Distributed Firewall теперь поддерживает рабочие нагрузки, развернутые на распределенных группах портов (Distributed Port Groups) распределенных коммутаторов (VDS). Это позволяет реализовать фаервол NSX без внесения изменений в vSphere Distributed Switch и без конвертации портов в N-VDS, а также без развертывания сетевых оверлеев.

Улучшения сетевого взаимодействия и механизма политик

Здесь мы увидим 3 основных улучшения:

1. Работа с сетью и обеспечение безопасности для связки NSX-T и Antrea

Начиная с NSX-T 3.2, сетевые администраторы могут определить политики для Antrea в плане сетевых настроек и безопасности для контейнеров прямо из интерфейса NSX-T Manager. Политики применяются к кластерам Kubernetes на базе Antrea 1.3.1-1.2.2 с использованием interworking controller. Объекты K8s, такие как поды, пространства имен и сервисы, объединяются в инвентаре NSX-T и тэгируются, а значит их можно выбрать при настройке политик Distributed Firewall. Также NSX-T может управлять компонентом Antrea Traceflow и собирать лог-бандлы с кластеров, используя Antrea.

2. Улучшенный координатор миграции

NSX Migration Coordinator был улучшен, теперь он поддерживает определенные пользователем топологии NSX, больший масштаб развертываний и другие возможности, которые ранее не поддерживались, например, VMware Integrated OpenStack (VIO), фиксированные топологии OSPF, функции guest introspection для партнеров, которые поддерживают Migration Coordinator, а также конфигурации identity-based firewall (IDFW/RDSH).

3. Функции NSX Federation

Эти возможности впервые были представлены в NSX-T 3.0. Они позволяют через NSX Global Manager централизованно управлять распределенной виртуальной сетью в нескольких локациях, поддерживая их в синхронизированном виде с точки зрения конфигурации, политик безопасности и операционного управления. 

Теперь NSX Federation поддерживает репликацию тэгов виртуальных машин между local managers, что позволяет виртуальным машинам при восстановлении после сбоя сохранить нужные политики безопасности. Также в NSX-T 3.2 есть мониторинг состояния каналов коммуникации между global и local manager.

Улучшения настройки сети и операций

В этой категории VMware сделала 4 основных улучшения:

1. Улучшенное развертывание NSX

Теперь администраторы могут развернуть NSX-T manager и различные сценарии networking and security напрямую из клиентов vSphere. Также есть guided workflows, которые упрощают развертывание NSX Manager и настройку политик.

2. Упрощенное развертывание для NSX Advanced Load Balancer 

Установка NSX Advanced Load Balancer (ALB) теперь стала проще за счет тесной интеграции с NSX Manager. Вы можете использовать графический интерфейс NSX Manager для установки и настройки контроллеров NSX Advanced Load Balancer, после чего запустить ALB UI для настройки расширенных параметров. Также появились возможности по миграции своего решения по балансировке с NSX for vSphere на VMware NSX Advanced Load Balancer с использованием Migration Coordinator.

3. Поддержка vRealize Network Insight Support для NSX-T Federation and Firewall

Тесная интеграция между vRealize Network Insight 6.4 и NSX-T Federation позволяет улучшить сетевую видимость между разными датацентрами на базе NSX-T на разных уровнях: глобальном, региональном и уровне локального сайта. Новые возможности позволяют оптимизировать производительность и просмотр сетевых потоков VM-to-VM как в рамках одного сайта, так и между сайтами в рамках федерированной топологии. vRealize Network Insight 6.4 теперь поддерживает  NSX-T Distributed Firewall (DFW) на распределенных порт-группах (Distributed Port Groups, DVPG), что дает дополнительные возможности анализа незащищенных потоков трафика, возможности безопасности, такие как Name Space (NS) groups, а также правила распределенного фаервола на существующих группах vSphere VLAN DVPG.

4. Улучшения сетевого мониторинга и механизма решения проблем

Новые функции Edge и L3 time-series monitoring позволяют получить представления во времени для метрик Edge и L3, такие как использование CPU, памяти, диска, пакетов в секунду, байтов в секунду, packet drop rate и многое другое в NSX Manager. Это позволяет сетевым администраторам получать больше данных для анализа в историческом контексте. Функции Live Traffic Analysis в NSX Manager дают возможность производить оперативную диагностику и решение проблем в плане состояния кластера, компонентов управления, федерации, состояния транспортных узлов, distributed firewall, Edge, VPN, NAT, Load Balancing и платформы NSX Application Platform. 

На днях компания VMware объявила о доступности для загрузки VMware Cloud Director 10.3, решения для сервис-провайдеров, предоставляющих виртуальные машины в аренду, которым нужна интегрированная платформа управления облаком. Напомним, что о прошлой версии этого продукта (10.2) мы писали весной этого года вот тут.

Давайте посмотрим на основные новые возможности VCD 10.3:

• Поддержка Kubernetes - тут появились такие новшества, как поддержка кластеров Tanzu Kubernetes для NSX-T Data Center group networking. Теперь для отдельных сервисов можно включить внешний доступ в рамках data center group.
• Сервис-провайдеры и клиенты могут делать апгрейд кластеров Tanzu Kubernetes с использованием графического интерфейса, а также использовать vRealize Operations Tenant App для учета потребления ресурсов Kubernetes.
• Клиенты могут использовать единую точку доступа API для всех операций жизненного цикла решений Tanzu Kubernetes Grid Service, Tanzu Kubernetes Grid и непосредственно Kubernetes.
• Улучшения интерфейса по работе с режимом FIPS-compliant.
• Поддержка в API приложений vApp при их перемещении между vCenter.
• Улучшения интерфейса при работе с каталогом.
• Поддержка VMware Cloud Director Service Library для vRealize Orchestrator 8.x (для этого есть vRealize Orchestrator plug-in, который позволяет имплементировать рабочие процессы vRO для клиентов VCD).
• Улучшенные функции поиска Quick Search и Global Search в интерфейсе.
• Улучшения производительности расширения Auto Scaling.
• Поддержка vApp network services в окружении NSX-T - вы можете использовать NAT, фаервол и статическую маршрутизацию для сетей виртуальных приложений vApp.
• Поддержка Distributed Firewall Dynamic Group Membership в окружении NSX-T - можно создавать группы безопасности ВМ с динамическим членством, которое основано на базе различных параметров ВМ (например, шаблон имени или тэги). Для таких групп можно создавать правила фаервола, что позволяет микросегментировать сетевой трафик и эффективно защищать группы ВМ.
• Сервис-провайдеры могут создавать внешние сети на базе VLAN и оверлеев сегментов NSX-T Data Center.
• Сервис-провайдеры могут импортировать сети на базе DVPG. Администратор может импортировать распределенную портгруппу из Distributed Switch и расшарить эти сети между группами датацентра.
• Поддержка VLAN и пулов port-group network pools для VDC на базе NSX-T Data Center.
• Поддержка создания VDC без ассоциации с NSX Data Center for vSphere, NSX-T Data Center Update port groups или внешними сетями.
• Поддержка решений Avi версий 20.1.3 и 20.1.4.
• Поддержка конфигурации DHCPv6 и SLAAC, а также назначения primary IP address шлюзу NSX-T edge gateway в интерфейсе.
• Поддержка создания и управления статическими пулами IPv6.
• Просмотр списка VDC group networks в интерфейсе.
• Улучшения назначений для Edge Cluster.
• Поддержка управления DHCP для изолированных сетей в VDC на базе NSX-T Data Center.
• Сервис-провайдеры могут менять основные настройки Avi SEG.
• Новый раздел Tier-0 Gateway Networking на портале Service Provider Portal.
• Аллоцированные IP-адреса DHCP видны на экране VM details.
• Можно изменять и удалять DHCP-пулы из сетей на базе NSX-T Data Center.
• Действие Reject для правил фаервола NSX-T Data Center edge gateway (также можно нотифицировать клиента о заблокированном трафике).
• Можно изменять приоритет правил NAT.
• Поддержка Reflexive NAT.
• Поддержка импортированных сетей VMware Cloud on AWS.
• Для внутренних подсетей поддерживаются службы Advertise services с механизмом route advertisement.
• Поддержка сетей /32 в качестве внешних для NSX-T Data Center.
• Поддержка Guest VLAN Tagging для сегментов сетей NSX-T Data Center.
• Доступность Alpha API - теперь администраторы могут использовать включенный по умолчанию API, который позволяет управлять кластерами Kubernetes Container Cluster, а также предоставляет возможности Legacy API Login.

Более подробную информацию о новом релизе VMware Cloud Director 10.3 можно получить в Release Notes. Скачать его можно по этой ссылке.

Команда PowerCLI компании VMware на днях выпустила обновление средства vSphere Desired State Configuration (DSC) версии 2.2. Механизм DSC есть в экосистеме Windows, начиная еще с Windows Server 2012 R2. С помощью него можно мониторить и управлять конфигурациями систем посредством специальных конфигурационных файлов на базе PowerShell, которые имплементируются через движок Local Configuration Manager (LCM), который должен быть на каждом хосте.

У VMware этот механизм работает несколько иначе, в качестве LCM используется прокси-хост, поскольку LCM не запустить ни на vCenter Server Appliance, ни на ESXi:

Так работал механизм до текущего момента, когда пользователям приходилось разворачивать отдельную Windows-машину под LCM. Но теперь появился модуль VMware.PSDesiredStateConfiguration, который предоставляет пользователям набор командлетов, чтобы скомпилировать и исполнить конфигурацию DCS без использования DSC Local Configuration Manager. Это позволяет использовать как Windows, так и Linux-машину в качестве прокси.

При этом пользователям по-прежнему предоставляется возможность использовать как vSphereDSC с движком PowerShell LCM, так и модуль VMware.PSDesiredStateConfiguration.

Давайте посмотрим, что нового появилось в DCS версии 2.2:

1. Новые ресурсы PowerCLI модуля

Вот они:

1. DatastoreCluster - создание, изменение, апдейт или удаление Datastore cluster
2. DatastoreClusterAddDatastore - добавление датастора к Datastore cluster
3. DRSRule - создание, изменение, апдейт или удаление правил DRS
4. VMHostVdsNic - изменение, апдейт или удаление "VMKernel nic" на vSphere Distributed switch
5. VMHostStorage - включение или отключение программного iSCSI-адаптера 
6. VMHostIScsiHbaVMKernelNic - используется для bind/unbind адаптеров VMKernel Network Adapters к указанному iSCSI Host Bus Adapter

2. Исправления ошибок

Поправлены ошибки в следующих командлетах:

• VMHostVDSwitchMigration 
• VMHostVssTeaming
• NfsDatastore

3. Операция Install/Update для модуля VMware vSphereDSC

Установка модуля теперь делается так:

Install-Module -Name VMware.vSphereDSC

Обновление вот так:

Update-Module -Name VMware.vSphereDSC

4. Новый модуль VMware.PSDesiredStateConfiguration

Как было сказано выше, теперь вы можете использовать Windows или Linux-машину без LCM для использования механизма DCS. Установить модуль можно следующей командой:

Install-Module -Name VMware.PSDesiredStateConfiguration

Новый командлет New-VmwDscConfiguration создает объект VmwDscConfiguration, который содержит информацию о конфигурации. Эту конфигурацию можно задать в ps1-файле и передать ее данному командлету. Например:

$config = New-VmwDscConfiguration -Path ./Site-A.ps1

Командлет Start-VmwDscConfiguration запускает исполнение конфигурации:

Start-VmwDscConfiguration -Configuration $config

Есть командлет Test-VmwDscConfiguration для проверки соответствия текущей конфигурации описанной:

Test-VmwDscConfiguration -Configuration $config

Можно также использовать параметр -Detailed для вывода полной информации по соответствию:

Test-VmwDscConfiguration -Configuration $config -Detailed

5. Новая динамическая конструкция vSphere Node

С помощью vSphere Node можно указать объект VINode (сервер vCenter или хост ESXi) и применить соответствующую конфигурацию к нужному узлу vSphere. Это дает следующие возможности:

• Персистентные сессии

Раньше для каждого подключения каждый ресурс требовал параметров учетной записи для установки сессии VISession. Теперь же если вы используете Vmware.PSDesiredStateConfiguration то можно создать персистентную VISession, которую можно использовать для всех ресурсов DCS.

• Не нужны файлы MOF

Поскольку LCM теперь не используется, то и для командлета New-VmwDSCconfiguration они не требуются. Конфигурация может храниться в переменной, либо в ps1-файле.

Скачать VMware vSphere DSC 2.2 можно по этой ссылке.

Некоторое время назад мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).

Устройства HCA могут коммуницировать с памятью приложений на сервере напрямую. Грубо говоря, если в обычном режиме (TCP) коммуникация по сети происходит так:

То при наличии на обоих хостах HCA, обмен данными будет происходить вот так:

Очевидно, что такая схема не только снижает нагрузку на CPU систем, но и существенно уменьшает задержки (latency) ввиду обхода некоторых компонентов, для прохождения которых данными требуется время.

Поддержка RDMA появилась еще в VMware vSphere 6.5, когда для сетевых адаптеров PCIe с поддержкой этой технологии появилась возможность обмениваться данными памяти для виртуальных машин напрямую через RDMA API. Эта возможность получила название Paravirtual RDMA (PVRDMA).

Работает она только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Метод коммуникации между виртуальными машинами в таком случае выбирается по следующему сценарию:

• Если две машины общаются между собой на одном ESXi, то используется техника memory copy для PVRDMA, что не требует наличия HCA-карточки на хосте, но сама коммуникация между ВМ идет напрямую.
• Если машины находятся на хостах с HCA-адаптерами, которые подключены как аплинки к VDS, то коммуникация идет через PVRDMA-канал, минуя обработку на CPU хостов, что существенно повышает быстродействие.
• Если в коммуникации есть хоть одна ВМ на хосте, где поддержки RDMA на уровне HCA нет, то коммуникация идет через стандартный TCP-туннель.

Начиная с VMware vSphere 7 Update 1, для PVRDMA была добавлена поддержка оконечных устройств с поддержкой RDMA (Native Endpoints), в частности хранилищ. Это позволяет передать хранилищу основной поток управляющих команд и команд доступа к данным от виртуальных машин напрямую, минуя процессоры серверов и ядро операционной системы. К сожалению для таких коммуникаций пока не поддерживается vMotion, но работа в этом направлении идет.

Чтобы у вас работала технология PVRDMA для Native Endpoints:

• ESXi должен поддерживать пространство имен PVRDMA. Это значит, что аппаратная платформа должна гарантировать, что физический сетевой ресурс для виртуальной машины может быть выделен с тем же публичным идентификатором, что и был для нее на другом хосте (например, она поменяла размещение за счет vMotion или холодной миграции). Для этого обработка идентификаторов происходит на сетевых карточках, чтобы не было конфликтов в сети.
• Гостевая ОС должна поддерживать RDMA namespaces на уровне ядра (Linux kernel 5.5 и более поздние).
• Виртуальная машина должна иметь версию VM Hardware 18 или более позднюю.

За счет PVRDMA для Native Endpoints виртуальные машины могут быстрее налаживать коммуникацию с хранилищами и снижать задержки в сети, что положительно сказывается на производительности как отдельных приложений и виртуальных машин, так и на работе виртуального датацентра в целом.

Компания VMware, сразу после анонсов новых версий VMware vSAN 7 Update 1 и VMware Cloud Foundation 4.1, объявила о скорой доступности для загрузки новой версии своей серверной платформы виртуализации VMware vSphere 7 Update 1.

Основной фишкой первого пакета обновления седьмой версии vSphere стал, конечно же, финальный выпуск платформы VMware vSphere with VMware Tanzu, объединяющей миры виртуальных машин и контейнеризованных приложений в рамках инфраструктуры предприятия.

Вот небольшой обзор платформы VMware vSphere with Tanzu, о первых объявлениях компонентов которой мы уже писали тут и тут (а о текущей версии рассказано в блоге VMware):

Нововведения vSphere 7 U1 разбиты на 3 блока:

• Инфраструктура для разработчиков (контейнеры)
• Продолжение масштабирования возможностей платформы
• Упрощение операций администраторов

Итак, давайте посмотрим, что нового в VMware vSphere 7 Update 1:

1. Инфраструктура для разработчиков

Здесь VMware добавила следующие важные возможности:

• Служба Tanzu Kubernetes Grid (TKG) - о ней мы упоминали вот тут. Она позволяет администраторам развертывать Kubernetes-окружения и управлять их составляющими с помощью решения для кластеров Tanzu Kubernetes. Делается это теперь за минуты вместо часов. Также TKG идет в соответствии с политиками upstream Kubernetes, что позволяет сделать процесс миграции максимально бесшовным.
• Bring Your Own Networking - пользователи могут выбирать, какой сетевой стек использовать для кластеров Tanzu Kubernetes. Можно использовать традиционную инфраструктуру на базе vSphere Distributed Switch (vDS) для конфигурации, мониторинга и администрирования виртуальных машин и кластеров Kubernetes. Новый Networking for Tanzu Kubernetes clusters позволяет использовать и решения VMware NSX. Также можно использовать Antrea для максимальной производительности внутренней сети для сервисов Tanzu Kubernetes Grid.
• Bring Your Own Load Balancer - можно выбирать тип балансировки L4 для кластеров Tanzu Kubernetes. Первым партнером VMware стало решение HAProxy в формате виртуального модуля OVA.
• Application-focused management - теперь пользователи могут применять vCenter не только для управления виртуальными машинами, но и для обслуживания, мониторинга и траблшутинга инфраструктуры контейнеров, включая приложения и неймспейсы (подход application focused management).

2. Продолжение масштабирования возможностей платформы

В этой категории нужно отметить следующие возможности:

• Monster VMs - для пользователей решений SAP HANA, Epic Operational Databases, InterSystems Cache и IRIS компания VMware позволяет масштабировать виртуальные машин до 24 ТБ памяти и до 768 виртуальных процессоров (vCPU). То есть все ресурсы хоста могут быть предоставлены виртуальной машине, требующей их большое количество. Это было сделано за счет улучшения планировщика ESXi, а также логики ко-шедулинга для больших ВМ.

• Cluster scale enhancements - теперь в   vSphere 7 U1 кластер может содержать до 96 хостов! Это на 50% больше значения в релизе vSphere 7 (64 штуки):

3. Упрощение операций администраторов

• vSphere Lifecycle Manager - теперь vLCM поддерживает и хосты vSAN, и конфигурацию сетевого стека NSX-T. В vSphere 7 Update 1 решение vLCM также мониторит соответствие образов непрерывно, что позволяет вовремя запустить процесс обновления (remediation).

• vSphere Ideas - эта функциональность позволяет пользователям запросить возможности vSphere следующих версий прямо из интерфейса vSphere Client, отслеживать статус своих запросов, видеть запросы других пользователей и голосовать за них. Не факт, конечно, что к вам прислушаются, но общую обстановку по тому, что хотят администраторы, вы будете видеть.

• vCenter Connect - теперь пользователи могут управлять своими виртуальными ресурсами VMware Cloud on AWS или в других облаках на базе vCenter из единого интерфейса.

Доступность для загрузки VMware vSphere 7 Update 1 ожидается в рамках или после конференции VMworld Online 2020. Следите за нашими обновлениями!

Как вы знаете, в продуктовой линейке VMware есть два решения, предназначенных для виртуализации сетей и централизованного управления сетевым взаимодействием виртуальных машин на уровне всего датацентра - это продукты NSX-T и NSX-V.

NSX-T предназначен для гибридных окружений, как в смысле поддержки разных гипервизоров (ESXi и KVM), так и в плане поддержки облачных инфраструктур (например, AWS). Решение NSX-V разработано специально для виртуальной среды VMware vSphere и использует виртуальные коммутаторы vSphere Distributed Switch (vDS). Оба решения могут быть использованы под одной лицензией, что дает пользователям гибкость при выборе нужного типа развертывания.

(картинка отсюда)

Давайте взглянем на сравнительную таблицу двух версий решений VMware NSX, где собраны основные ключевые отличия:

Ну и вот обзорное видео об основных отличиях NSX-T и NSX-V:

Не так давно мы писали о новых возможностях платформы для создания отказоустойчивых хранилищ виртуальных машин в инфраструктуре виртуализации VMware vSAN 7.0. Компания VMware недавно сделала доступными для загрузки все компоненты обновленной виртуальной инфраструктуры, но новые возможности получили далеко не все пользователи - их набор зависит от имеющейся лицензии.

Давайте посмотрим, какие возможности есть в каждом из четырех доступных изданий VMware vSAN 7.0:

	Standard (гибридные хранилища HDD+SSD)	Advanced (All-Flash хранилища)	Enterprise (возможности для предприятий)	Enterprise Plus (гиперконвергентная инфраструктура)
Возможности vSAN 7
Политики хранилищ Storage Policy Based Management (SPBM)
Распределенный коммутатор Virtual Distributed Switch
Распределение дисковых объектов по разным стойкам (Rack Awareness)
Контрольные суммы и обнаружение сбоев (Software Checksum)
Возможность использования оборудования All-Flash
Службы iSCSI Target
Функции QoS – IOPS Limit
Интерфейс управления HTML5
Функции Cloud Native Storage
Дедупликация и компрессия данных
Функции RAID-5/6 Erasure Coding
Возможности vRealize Operations внутри vCenter
Растянутый кластер (Stretched Cluster) с защитой от локальных сбоев
Шифрование Data-at-rest
Файловые службы
Издание vRealize Operations 8.0 Advanced
Функции балансировщика с поддержкой vSAN (resync, slack space, SPBM)
Кастомизируемые дэшборды
Функции Auto Remediation
Рабочие процессы для решения проблем
Функции интеллектуального размещения нагрузок Automated Intent-Based Workload Placement
Планирование емкостей (Capacity Planning)

Осенью прошлого года компания VMware выпустила VMware Cloud Foundation 3.9. Напомним, что это комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.

На днях было выпущено небольшое обновление архитектуры VCF 3.9.1, где появилось несколько небольших новых возможностей.

Главное обновление - это новый Bill of Materials (BoM) для последних версий продуктов (включая апдейты 2020 года):

Остальные новые возможности включают в себя:

• Функция Application Virtual Networks (AVN) - она позволяет решению vRealize Suite быть развернутым в сетях NSX overlay networks. AVN, которые являются стандартом по умолчанию, начиная с этой версии архитектуры VCF, предоставляют преимущества портируемости и быстрого восстановления после запланированного простоя или в случае аварии. Чтобы узнать больше об этих сетях и перевести компоненты vRealize Suite на эту технологию почитайте вот эту статью.
• Поддержка API для нескольких физических сетевых адаптеров и распределенных коммутаторов (vSphere Distributed switches). Теперь API поддерживает до трех vDS и до 6 физических NIC, что дает возможность применения API в высокопроизводительных средах с большим числом адаптеров и виртуальных коммутаторов (например, физическое разделение типов трафика).
• Улучшения Cloud Builder - обновленный графический интерфейс включает в себя несколько улучшений рабочих процессов, а также показывает в отчетах детали задач, которые были выполнены во время развертывания.
• Улучшения Developer Center - теперь можно получить доступ к Cloud Foundation API и примерам кода из дэшборда SDDC Manager.

Более подробная информация об улучшениях VMware Cloud Foundation 3.9.1 приведена в Release Notes.

На сайте проекта VMware Labs появилась еще одна интересная утилита - vCenter Plugin for vRealize Network Insight. С помощью данного плагина для управляющего сервера vCenter можно получить всю необходимую информацию от решения VMware vRealize Network Insight (vRNI) в консоль vSphere Client в виде отдельного раздела.

Это все позволяет администраторам виртуальной инфраструктуры VMware vSphere видеть информацию о сетевом взаимодействии в виртуальном датацентре и потоках виртуальных машин сразу в клиенте vSphere, без необходимости постоянно переключаться между двумя консолями:

Возможности плагина:

• Верхнеуровневый обзор активности vCenter: виртуальные машины, миграции vMotion и снапшоты.
• Отображение сетевой информации напрямую в vCenter:
  • Представление поведения внутреннего сетевого трафика east-west, сколько трафика расходуется.
  • Нарушение жизнедеятельности (хэлсчеков) для vCenter и прикрепленных к нему NSX-окружений.
  • Самые использующие сеть виртуальные машины, сгруппированные по именам, кластерам, сетям L2, подсетям, группам безопасности, паре источник-назначение, сети источник-назначение, IP-адресам источника и назначения.
  • Самые используемые сети.
  • Новые виртуальные машины, использующие интернет-трафик (полезно для обнаружения подозрительных активностей).
  • Топ-5 хостов и сетей, в которых наблюдается наибольшая потеря пакетов.
• Ссылка на консоль vRealize Network Insight, показывающие исходные данные и позволяющие глубже провалиться в детали. Можно применять фильтры, экспортировать данные и другое.
• Возможность настройки vCenter как источника данных и настройка NetFlow на доступных распределенных коммутаторах vSphere Distributed Switches.

Скачать vCenter Plugin for vRealize Network Insight можно по этой ссылке. Инструкции по развертыванию доступны тут.